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:
> 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
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation