Skip to main content

[jsr356-users] [jsr356-experts] Fwd: Re: Re: Server deployment

  • From: Mark Thomas < >
  • To:
  • 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 
< >
To:     

CC:     Danny Coward 
< >,
 Mark Thomas
< >




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
>





[jsr356-users] [jsr356-experts] Fwd: Re: Re: Server deployment

Mark Thomas 12/07/2012

<Possible follow-up(s)>

[jsr356-users] [jsr356-experts] Fwd: Re: Re: Server deployment

Mark Thomas 12/07/2012
 
 
Close
loading
Please Confirm
Close