On 11/30/2012 09:49 AM, Mark Thomas wrote:
>
> 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.
+1
I also prefer something based on the existing SCI mechanism. It was a
hard sell to the Servlet EG when it was introduced, but it allows
avoiding scanning the deployment more than once. It is really the only
mechanism that is acceptable for scanning [in case of issues, some
tweaks could be possible in Servlet 3.1].
Rémy