https://issues.apache.org/bugzilla/show_bug.cgi?id=54740
Mark Thomas changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://issues.apache.org/bugzilla/show_bug.cgi?id=54740
rstoyanc...@yahoo.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution
https://issues.apache.org/bugzilla/show_bug.cgi?id=54740
Mark Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://issues.apache.org/bugzilla/show_bug.cgi?id=54740
--- Comment #3 from rstoyanc...@yahoo.com ---
Actually it appears that ServerEndpointConfig types should not be scanned at
all. Here is an explanation by Danny on the EG:
http://java.net/projects/websocket-spec/lists/jsr356-experts/archive/2
https://issues.apache.org/bugzilla/show_bug.cgi?id=54740
--- Comment #2 from rstoyanc...@yahoo.com ---
I posted questions on the EG list
(http://java.net/projects/websocket-spec/lists/jsr356-experts/archive/2013-03/message/41).
Hopefully this get clarified in the spec. Either way it makes sense th
https://issues.apache.org/bugzilla/show_bug.cgi?id=54740
--- Comment #1 from Mark Thomas ---
The Servlet 3.0 scanning mechanism only requires that the class may be loaded.
The WebSocket spec limits @ServerEndpoint to "public, concrete, and have a
public no-args constructor". It seems reasonable
