[jsr356-users] [jsr356-experts] Re: from Rajiv: Re: Server deployment
- From: Mark Thomas <
- Subject: [jsr356-users] [jsr356-experts] Re: from Rajiv: Re: Server deployment
- Date: Sat, 08 Dec 2012 11:55:11 +0000
- List-id: <jsr356-experts.websocket-spec.java.net>
On 07/12/2012 23:25, Danny Coward wrote:
> Thanks Mark.
> Let me see if I can turn what we have concluded into a proposal for our
> 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.
I don't think we'll need that. If scanning is disabled completely, there
will be no need for implementations of ApplicationConfig. I think it is
reasonable to say if you want to use scanning and filter the results
then your ApplicationConfig has to be in a JAR that will be scanned.