Skip to main content

[jsr356-experts] Re: Server deployment

  • From: Mark Thomas < >
  • To:
  • Subject: [jsr356-experts] Re: Server deployment
  • Date: Fri, 07 Dec 2012 17:41:43 +0000

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.

> If so then we are good.

Great.

Mark



[jsr356-experts] Re: Server deployment

Danny Coward 12/06/2012

[jsr356-experts] Re: Server deployment

Mark Thomas 12/07/2012

[jsr356-experts] Re: Server deployment

Danny Coward 12/07/2012
 
 
Close
loading
Please Confirm
Close