Hi Danny,
Both A and B avoid reliance on an SCI scan.
Option A however is a much more natural fit for Servlet users. Servlet 3.0 added a Java API for registering Servlets and Filters. Having to spell fully qualified class names in web.xml is hardly agreement with that theme. The use of annotations and scanning in the WebSocket API itself are meant to avoid uncompiled references to classes I presume? Deployment shouldn't require it either as option B does.
It's not clear when option B occurs in the lifecycle of the container relative to the initialization of ServletContextLstener's, Filter's, Servlet's, and ServletContainerInitializer's. At the same time option A allows any of those to register endpoints while still meeting the requirement to do so at startup. Applications and frameworks already use such components to load configuration, certainly the Spring Framework does, and so do many frameworks that use or support Spring configuration. Option B doesn't seem to offer anything new in terms of when in the lifecycle registration takes place and what information is available.
Rossen
----- Original Message -----
> From: "Danny Coward" <danny.coward_at_oracle.com>
> To: jsr356-experts_at_websocket-spec.java.net
> Sent: Wednesday, February 20, 2013 8:03:16 PM
> Subject: [jsr356-users] [jsr356-experts] More programmatic endpoint
> deployment
> Hi folks,
> OK so if I understand it from Mark and Rossen, the usecase for
> programmatic deployment is to be able to deploy any server endpoint
> (programmatic or annotated) contained within the WAR, irrespective
> of whether there is a scan on the WAR. And if I understand
> correctly, it is sufficient only to be able to do so at application
> deployment time.
> I think its right for this version not to be contemplating being able
> to programmatically deploy endpoints at any arbitrary time in the
> lifetime of an application. I'm just not sure what side effects
> there are of dynamically adding to an application at runtime, and
> we'd probably have to think of an analogous undeploy mechanism. That
> sort of thing I think belongs in some future version. Though of
> course containers can always provide their own ways to do this now,
> if they are brave !
> But back to the requirement: currently, we have developer provided
> ServerApplicationConfigurations to which the implementation passes
> the results of the archive scan and out of which the implementation
> gets a collection of endpoints (annotated endpoint classes or
> EndpointConfig instances for programmatic endpoints).
> So to meet the requirement (which I would like us to), we have two
> ideas:-
> A) a programmatic API that can be called during application
> deployment.
> B) Some expansion of ServerApplicationConfiguration that doesn't
> depend on a scan.
> To get into A) a bit more, we would need a few extra things as well
> as the actual methods:
> - first, a bootstrap point to be able to call the programmatic API at
> the correct time: bootstrapping the correct time to make the call in
> the lifecycle could be done inside a developer provided
> ServletContextInitializer.
> - second: to obtain a reference to the WebSocketContainer I guess the
> spec could define a named ServletContext attribute, for example
> ServletContext.getAttribute("javax.websocket.server.ServerContainer").
> - third: we would need to throw (runtime?) exceptions if the
> programmatic deployment API was called at the wrong time.
> To get into B) a bit more, we could define new interface, analogous
> to ServerApplicationConfiguration, let's say
> "NonScanApplicationConfiguration" just for now, with methods.
> NonScanApplicationConfiguration
> - Set<ServerEndpointConfiguration> getEndpointConfigurations();
> - Set<Class<?>> getAnnotatedEndpointClasses();
> Developer could implement these at will, package them in the WAR same
> as ServerApplicationConfiguration. The spec would need to define a
> web.xml context-param name, say
> "javax.websocket.server.NonScanApplicationConfiguration", and value
> a comma separated list of developer implementations thereof. The
> container picks them up (instead of doing a scan) and build the
> deployment list from there.
> I think A) and B) both meet the requirement. Right ?
> At first I thought the programmatic API was going to turn out
> simpler, but when I look at all the pieces, I'm thinking the second
> approach B) is simpler. Its seems to be more consistent with the
> existing scan based approach, the mechanism is more self-contained
> in the websocket spec, and the callback enforces the 'deploy at
> application initialization time' better. Also, if we do a full
> dynamic deployment API in the future, we'd have to fit it round this
> more limited API.
> Could we live with B) ?
> - Danny
> --
> Danny Coward
> Java EE
> Oracle Corporation