On 23/11/2012 23:04, Mark Thomas wrote:
> 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.
Just ignore me (again!). It was late and I was tired :) I'd forgotten
about the clarification in the Servlet 3.0 MR that made clear the
relationship between SCIs, @HandlesTypes and annotations. This is doable
and intend to follow this approach with the Tomcat implementation.
Mark