[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:37 +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:24:32 -0800
From: Rajiv Mordani
CC: Danny Coward
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. "
> 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.
> 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.
> <http://www.oracle.com> *Danny Coward *
> Java EE
> Oracle Corporation