Skip to main content

[jsr356-users] [jsr356-experts] Re: from Rajiv: Re: Server deployment

  • From: Mark Thomas < >
  • To: Rajiv Mordani < >
  • Cc: , Danny Coward < >, "CHAN,SHING WAI" < >
  • Subject: [jsr356-users] [jsr356-experts] Re: from Rajiv: Re: Server deployment
  • Date: Sat, 08 Dec 2012 12:06:27 +0000
  • List-id: <jsr356-experts.websocket-spec.java.net>

On 07/12/2012 23:03, Rajiv Mordani wrote:
> 
> On 12/7/12 12:10 PM, Mark Thomas wrote:
>> On 07/12/2012 19:23, Danny Coward wrote:
>>> forwarding this from Rajiv as he is 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
>>
>> Thanks for the clarification. I hadn't quite read it like that.
>>
>> My instant reaction is that is going to cause a problem but let me think
>> it through.
>>
>> The Servlet 3.0 specification clearly expects SCIs at the container
>> level to be honoured. Section 8.2.4 describes such a scenario. If the
>> SCI specifies @HandlesTypes then the applications are going to have to
>> be scanned for annotations.
> 
> Yes that is correct.
> 
>>
>> Based on my current understanding (specifically for WebSocket)...
>>
>> What is possible:
>> - the JARs to be scanned for WebSocket annotations within the
>> application can be controlled by an absolute ordering with the web
>> application's web.xml
>> - controlling which of the discovered WebSocket endpoints are deployed
>> wil be controlled by the WebSocket specific ApplicationConfig class.
>>
>> What is not possible (within the specs):
>> - disabling the WebSocket SCI on either a global or per application basis
>>
>> What I am trying to figure out is if not being able to disable the
>> WebSocket SCI is an issue.
> 
> JAX-RS uses a similar approach and they have not had a need to disable
> discovering JAX-RS endpoints. So unless there is a good reason for doing
> this
> I don't see why WebSocket would need this to happen.
> 
>>
>> Possible scenarios:
>> a) Application has WebSocket annotations and wants to scan for them
>>     No issue here
>>
>> b) Application has no annotations and wants to disable scanning
>>     No issue (use absolute ordering)
>>
>> c) Application has annotations @FooBar and wants to scan for them but
>>     does not want to scan for @WebSocket because none exist
>>     Unlikely to be a performance issue since it is scanning vs not
>>     scanning that creates the noticeable performance difference, not how
>>     many annotations types are scanned for
>>
>> d) Application has annotations @FooBar and wants to scan for them but
>>     does not want to scan for @WebSocket because although they exist in
>>     the app, they are not required.
>>     Disable via WebSocket's ApplicationConfig
> 
> I haven't looked at ApplicationConfig but if this is similar to JAX-RS
> Application class then you can achieve what you are saying via the
> ApplicationConfig
> class.
> 
>>     Unlikely to be a performance issue since it is scanning vs not
>>     scanning that creates the noticeable performance difference, not how
>>     many annotations types are scanned for
>>
>> So I think we are OK. Not ideal, as disabling is a little more complex
>> than I would like but it is all possible.
>>
>> There are other possible solutions such as container specific
>> configuration that treats container provided JARs as if they are in
>> WEB-INF/lib but they are firmly in the container specific solutions area.
> 
> Again I would like to understand why would we want to disable scanning
> at all. The SCIs
> are looked up via the Services API so you don't need to scan for the
> SCIs, the types that
> it is looking for has to be scanned in the appication. Unless you have a
> *lot* of classes
> in the application I don't think that there should be a noticeable
> difference to
> load an application.

That all depends on how you define noticeable (and how you do the
scanning). We have had some Tomcat users complain about application
start time with scanning enabled. We've improved the efficiency of the
scanning process a lot since the early releases but we do still get some
complaints. You are correct that it tends to be from people with very
large applications.

For users that don't want any scanning, they can use
<absolute-ordering/>

Mark


[jsr356-users] [jsr356-experts] from Rajiv: Re: Server deployment

Danny Coward 12/07/2012

[jsr356-users] [jsr356-experts] Re: from Rajiv: Re: Server deployment

Mark Thomas 12/07/2012

[jsr356-users] [jsr356-experts] Re: from Rajiv: Re: Server deployment

Danny Coward 12/07/2012

[jsr356-users] [jsr356-experts] Re: from Rajiv: Re: Server deployment

Mark Thomas 12/08/2012

[jsr356-users] [jsr356-experts] Two AppConfig options for Server deployment

Danny Coward 12/11/2012

Message not available

Message not available

[jsr356-users] [jsr356-experts] Re: from Rajiv: Re: Server deployment

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