Danny Coward <danny.coward_at_oracle.com> wrote:
>OK, so how about this, we say that:-
>
>developers enable/disable endpoint scanning using the web.xml's
>metadata-complete= true | false (don't scan, scan)
-1
Short version:
It will make a stand-alone JAR implementation really painful.
Long version:
metadata-complete controls whether or not a Servlet container scans JARs for Servlet annotations (Servlets, Filters and Listeners). The mechanism by which other components can scan for classes of interest is the @HandlesTypes annotation on a ServletContextInitializer (SCI). metadata-complete has no impact on SCI processing. If we take the approach suggested above we would have to package our own class scanning within the WebSocket JAR.
The approach that would be in line with what the Servlet 3.0 EG intended would be:
developers enable/disable endpoint scanning using the web.xml's fragment ordering. If the WebSocket JAR is included in the ordering then endpoint scanning will occur, if the WebSocket JAR is not included in the ordering then endpoint scanning will not occur.
How about this:
Scanning approach:
- SCI that scans for Endpoint, WebSocketEndpoint and ApplicationConfig
ApplicationConfig has a simple API:
boolean enable(Class<?> clazz)
If one or more instances of ApplicationConfig are present, then each Endpoint or class annotated with @WebSocketEndpoint is passed to each ApplicationConfig. If any ApplicationConfig instance returns true, that endpoint is deployed.
Scanning is disabled by removing the websocket implementation JAR from the fragment ordering. Alternatively a developer could provide a single instance of ApplicationConfig that returned false for everything but that would be inefficient since scanning would still happen.
Programmatic approach (as now):
- ServletContextListener
Uses ContainerProvider.getServerContainer to register endpoints.
Mark