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