Issue Details (XML | Word | Printable)

Key: WEBSOCKET_SPEC-53
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: dannycoward
Reporter: jitu
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
websocket-spec

Endpoint class qualifiers for @WebSocketEndpoint

Created: 26/Oct/12 06:28 PM   Updated: 05/Feb/13 12:56 AM  Due: 05/Feb/13   Resolved: 05/Feb/13 12:56 AM
Component/s: None
Affects Version/s: None
Fix Version/s: None

Time Tracking:
Not Specified

Tags: v012
Participants: dannycoward and jitu


 Description  « Hide

Define whether the endpoint class needs to be public, or final ? Can it be abstract etc ? Also make sure it is conformant with other EE specs.



dannycoward added a comment - 30/Oct/12 07:18 PM

See section 4.1 of the spec which refers additionally to 7.3.1.

Jitu: Let me know if you think anything is missing, I'm following standard practice with, for example, JAX-RS.


jitu added a comment - 31/Oct/12 12:13 AM

JAX-RS resources need not have zero-org constructors. See chapter 3.1.2. But it is odd that it doesn't specify any other requirements.

From the definition, the following is allowed (but it cannot be instantiated)

@WebSocketEndpoint
abstract class A {
public A() {
}
}


dannycoward added a comment - 31/Jan/13 09:04 PM

OK. We certainly can't have non-public abstract classes.

"The class must be public, concrete, and have a public no-args constructor. The class may or may not be final, and may or may not have final methods."

Let me know if there are other types you think we have to allow for v 1.0 as a priority.


dannycoward added a comment - 05/Feb/13 12:56 AM

What I proposed has been out to the expert group with no comment, so I am closing this out.

We might look at expanding the possibilities in the next version, but I think this is clear and simple for this version.