Fwd from Rajiv
-------- Original Message --------
Subject: Re: [jsr356-users] [jsr356-experts] Re: Server deployment
Date: Fri, 07 Dec 2012 11:24:32 -0800
From: Rajiv Mordani <rajiv.mordani_at_oracle.com>
To: jsr356-experts_at_websocket-spec.java.net
CC: Danny Coward <danny.coward_at_oracle.com>, Mark Thomas
<mark_at_homeinbox.net>
On 12/7/12 11:15 AM, Danny Coward wrote:
> Hi Mark,
>
> Thanks, pls see below...
> 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.
> OK so I also went back to reading the servlet spec 3.0 and section
> 8.2.2 in particular, and it does say there that the JAR has to be in
> the WAR:-
>
> " 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. "
> servlet.book
>
> And so then I checked with Rajiv and Shing Wai and that is their
> interpretation also :(
>
> Perhaps just for my own sanity, is honoring web-fragments from
> non-co-bundled JARs something that the servlet spec allows
> implementations to do, but doesn't actually explicitly require them to
> do ? Or is there some other piece that I am missing ?
No web-fragments cannot be in non-co-bundled JARs. We discussed this in
the servlet 3.0 and it was for scanning reasons that we limited it to
*only* be in the WAR file. It is a requirement that web-fragments MUST
be bundled in the war file.
- Rajiv
>
> Obviously, its important for us that this is clear since we want to be
> able to turn off scanning, but we also do not want to require
> developers have to co-bundle the websocket implementation in their WAR
> files to do so.
>
> - Danny
>
>>> If so then we are good.
>> Great.
>>
>> Mark
>>
>
>
> --
> <http://www.oracle.com> *Danny Coward *
> Java EE
> Oracle Corporation
>