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: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 
< >
To: 

CC: Mark Thomas 
< >,
 Danny Coward
< >,
        "CHAN,SHING WAI"
< >


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 
>>> < >
>>>  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
>





[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