Skip to main content

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

  • From: Danny Coward < >
  • To:
  • Cc: Mark Thomas < >, Rajiv Mordani < >
  • Subject: [jsr356-experts] Re: from Rajiv: Re: Server deployment
  • Date: Fri, 07 Dec 2012 15:25:07 -0800

Thanks Mark.

Let me see if I can turn what we have concluded into a proposal for our spec.

We define an ApplicationConfig type in the API that returns, on demand, a list of endpoints that must be deployed. Web Socket developers may include ApplicationConfigImpls in the WAR file (including in sub-JAR files). The websocket implementation must deploy the union of all the endpoints returns by all the ApplicationConfigImpls.

If no ApplicationConfig's are present in the WAR file, the websocket implementation must deploy all the endpoints in the WAR file that are the result of the SCI scan.

Then developers can:-

deploy all the endpoints in a WAR file just by including the code for them, [no config/nothing excluded from the scan]
deploy precisely which endpoints in a WAR file we want by providing one or more ApplicationConfigImpls
Limit the scanning performed by the SCI by excluding contained JARs from the SCI scan

Additionally, I think this means the ApplicationConfigImpls themselves cannot be discovered by scanning, and we will need to define a servlet-context parameter to be able to make them discoverable by the web socket implementation.

- Danny


On 12/7/12 12:15 PM, Mark Thomas wrote:
" type="cite">
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


--
Danny Coward
Java EE
Oracle Corporation


[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