Not all server implementations will be within a Servlet container.
The way the JSR-356 spec keeps the servlet-api at arms length is ideal. +1
from me (and I'm a committer to Jetty!)
Example use case: a javax.webSocket library implementation for mobile.
Separate Server and Client libraries, neither of which needs a Servlet
container to work.
Client library is (hopefully) obvious, and can be used to connect to remote
websocket servers.
But if the app wants to receive websocket connections (in a peer to peer
scenario, think gaming or chat), then there is no need for a full blown
http server container if they only want to support websocket.
As someone who has ported a servlet container to both J2ME and Android, I
can tell you that you don't always have ClassLoaders that you can
walk/iterate through or even have access to the concept of Jars.
While there are ways to simulate desktop behavior on mobile with regards to
ClassLoader entry iteration and Jars, they don't really have the same
semantics and are very harmful to performance, memory, and battery life on
mobile devices.
--
Joakim Erdfelt <joakim_at_intalio.com>
webtide.com <http://www.webtide.com/>
Developer advice, services and support
from the Jetty & CometD experts
eclipse.org/jetty - cometd.org
On Thu, Feb 21, 2013 at 1:05 PM, Rossen Stoyanchev
<rstoyanchev_at_vmware.com>wrote:
> 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
>
> ------------------------------
>
> *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
> --
> <http://www.oracle.com> * Danny Coward *
> Java EE
> Oracle Corporation
>
>
>