forwarding this from Rajiv as he is not on the list
-------- Original Message --------
Subject: Re: [jsr356-users] [jsr356-experts] Re: Server deployment
Date: Fri, 07 Dec 2012 11:13:20 -0800
From: Rajiv Mordani <rajiv.mordani_at_oracle.com>
To: jsr356-experts_at_websocket-spec.java.net
CC: Mark Thomas <mark_at_homeinbox.net>, Danny Coward
<danny.coward_at_oracle.com>, "CHAN,SHING WAI" <shing.wai.chan_at_oracle.com>
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 <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.
> 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"
- Rajiv
>
>> If so then we are good.
> Great.
>
> Mark
>