[jsr356-users] [jsr356-experts] Fwd: Re: Re: Server deployment
- From: Mark Thomas <
- Subject: [jsr356-users] [jsr356-experts] Fwd: Re: Re: Server deployment
- Date: Fri, 07 Dec 2012 19:24:11 +0000
- List-id: <jsr356-experts.websocket-spec.java.net>
Fwd from Rajiv...
-------- Original Message --------
Subject: Re: [jsr356-users] [jsr356-experts] Re: Server deployment
Date: Fri, 07 Dec 2012 11:13:20 -0800
From: Rajiv Mordani
CC: Mark Thomas
On 12/7/12 9:41 AM, Mark Thomas wrote:
> 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.
Please forward to the JSR 356 EG as I am not on the list -
Mark this is not accurate. fragments MUST reside within the war file. It
is specified in Servlet 3.0 specification in Section 8.2.1 - For your
reference I am pasting the relevant text -
"If a framework wants its META-INF/web-fragment.xml honored in such a way
that it augments a web application's web.xml, the framework must be bundled
within the web application's WEB-INF/lib directory"
>> If so then we are good.