On 11/24/12 2:19 AM, Mark Thomas wrote:
> 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.
OK well its good to know it works !
But you made me think (and your suggestion from the EL spec) about
perhaps tidying up our deployment approach to make it consistent between
programmatic endpoints and POJOs. See an upcoming mail on that.
- Danny
>
> Mark
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation