[jsr356-experts] Re: Server deployment
- From: Mark Thomas <
- Subject: [jsr356-experts] Re: Server deployment
- Date: Fri, 07 Dec 2012 17:41:43 +0000
On 06/12/2012 23:41, Danny Coward wrote:
> Hi Mark,
> On 11/30/12 12:49 AM, Mark Thomas wrote:
>> Danny Coward
>>> 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.
Easily done. I made the same mistake and it wasn't until the Servlet 3.1
EG discussion on what was meant to happen that I realised my error. I'm
99% sure I have it right now ;)
>> 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 ?
Yes, that works and it works both ways. Scanning can be enabled/disabled
via absolute-ordering even if the JAR with the fragment is provided by
the container rather than the webapp.
> If so then we are good.