users@websocket-spec.java.net

[jsr356-users] [jsr356-experts] Re: Re: Bootstrapping Web Socket Applications in different places

From: Mark Thomas <mark_at_homeinbox.net>
Date: Fri, 23 Nov 2012 23:04:40 +0000

On 23/11/2012 18:03, Mark Thomas wrote:
> On 13/11/2012 22:56, Danny Coward wrote:
>> Well, then I propose we just stick with the ContainerProvider idea now:
>> it does the job it needs to. I think we will need separate facade
>> classes for client and server.
>
> Just a thought. You might want to cast an eye over how the EL spec
> handles obtaining a reference to an ExpressionFactory, particularly the
> options for different implementations.

Ignore that. I've spent a little longer looking at this and I don't see
how a WebSocket implementation could realistically be provided as a JAR
you could just "drop in" to any Servlet 3.1 container. The primary issue
is that of annotation scanning. There is no standard API for "scan for
annotations of type xxx" which means a container neutral implementation
would have ship with it's own class scanning code and that is before you
get in to figuring out which classes should and should not be scanned
based on Servlet 3.1 web fragment rules and meta-data complete.

While all these problems are solvable, the resulting code complexity,
duplicated functionality and performance impacts are significant.

If we wanted to go for the "drop in" JAR approach (I recall that there
was some desire to do this) we are going to need to make some major
changes to the API and/or place some additional requirements on the
Servlet EG.

Mark