Skip to main content

[jsr356-experts] Re: Server deployment

  • From: Danny Coward < >
  • To:
  • Cc: Mark Thomas < >
  • Subject: [jsr356-experts] Re: Server deployment
  • Date: Thu, 06 Dec 2012 15:41:43 -0800

Hi Mark,

On 11/30/12 12:49 AM, Mark Thomas wrote:
" type="cite">

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

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.
" type="cite">

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
" type="cite">

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.


Danny Coward
Java EE
Oracle Corporation

[jsr356-experts] Re: Server deployment

Danny Coward 12/06/2012

[jsr356-experts] Re: Server deployment

Mark Thomas 12/07/2012

[jsr356-experts] Re: Server deployment

Danny Coward 12/07/2012
Please Confirm