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