On 28/11/2012 22:48, Danny Coward wrote:
> So I'm suggesting a change to the server deployment to meet these goals,
> which goes like this:-
>
> 1) On deployment, the websocket server scans the WAR file for
> programmatic endpoints and POJOs. If no other configuration information
> exists in the WAR file (see 2) then all the programmatic endpoints and
> all the POJOs in the WAR file are deployed on startup.
> 2) We introduce an ApplicationDeployment type into the websocket API for
> developers who want finer grained control over which endpoints in the
> WAR file get deployed. This type is implemented by developers and
> co-packaged in the WAR file. Its function is to return on demand a list
> of all the programmatic endpoints and POJOs the container should deploy
> at deployment time. The exact API semantics TBD for now.
> 3) We no longer need the ServerContainer.publishServer() method, and
> consequently, there is no need for the entry point
> ContainerProvider.getServerContainer().
>
> An alternative to 2) is to define a static configuration mechanism, like
> a deployment descriptor. These seem to have gone out of fashion in the
> EE platform, but it could fulfill the same function (and is consistent
> with several sister specs).
>
> Please let me know your thoughts on this approach, I'd like to clean
> this up quite soon,
I dislike any approach which mandates some form of scanning. Scanning a
WAR is a potentially expensive business and can cause significant (and
unacceptable for some users) delay on application start. There needs to
be some mechanism (programmatic, static, whatever) that enables a
developer to tell the container "deploy this and this exactly and don't
do anything else".
I think the current solution isn't far off. A
ServletContainerInitializer can be annotated with @HandlesTypes for
Endpoint and @WebSocketEndpoint. Those that don't want scanning can
disable the SCI and use a ServletContextListener and do things
programmatically via ContainerProvider.getServerContainer().
I have no objection to re-factoring the current solution or even a
complete replacement but I do want to see the capabilities retained to:
- disable class scanning
- explicitly define what is to be deployed with requiring any form of
class scanning
Mark