users@websocket-spec.java.net

[jsr356-users] [jsr356-experts] Re: Server deployment

From: Danny Coward <danny.coward_at_oracle.com>
Date: Thu, 06 Dec 2012 15:41:43 -0800

Hi Mark,

On 11/30/12 12: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.
My bad, I misunderstood the meta-data-complete mechanism.
>
> 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.
OK, so that would give us a way to offer to developer to turn off
scanning in the SCI, which is what we would like.

I do have one concern about using the web fragment ordering to disable
the scanning, is that I don't want websocket developer to have to
co-bundle any websocket implementation artifacts in the WAR file for
Java EE.

So does what you suggest work in that case Mark ? that is to say:
excluding the web-fragment name of the implementation JAR from the web
fragment ordering, even though the implementation JAR is part of the
container, not the WAR ?

If so then we are good.

- Danny
>
> 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


-- 
<http://www.oracle.com> 	*Danny Coward *
Java EE
Oracle Corporation