Skip to main content

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

  • From: Mark Thomas < >
  • To:
  • Cc: Rajiv Mordani < >
  • Subject: [jsr356-experts] Re: from Rajiv: Re: Server deployment
  • Date: Fri, 07 Dec 2012 20:15:54 +0000

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.

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.

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

Cheers,

Mark


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

Danny Coward 12/07/2012

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

Mark Thomas 12/07/2012

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

Danny Coward 12/07/2012

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

Mark Thomas 12/08/2012

[jsr356-experts] Two AppConfig options for Server deployment

Danny Coward 12/11/2012

Message not available

Message not available

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

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