On Sep 25, 2009, at 11:07 AM, Viktor Klang wrote:
>
>
> On Fri, Sep 25, 2009 at 10:55 AM, Paul Sandoz <Paul.Sandoz_at_sun.com>
> wrote:
> Hi,
>
> I have thought some more about this and the following may be what is
> required:
>
> 1) An AtmosphereJerseyServletContainer that extends or adapts
> ServletContainer.
> That servlet can be referred to in the web.xml.
>
> The configure method of ServletContainer can be overridden to
> modify the ResourceConfig.
>
> 2) Modify ResourceConfig so that filters can be added
> programatically.
>
> Nice to have:
>
> 3) Declare Guice/Spring support using a context listener.
> Because a specific servlet is declared we need another
> mechanism to declare support rather than the current
> mechanism of using Guice/Spring specific servlets. I think
> this approach is useful anyway.
>
> 4) When underlying Servlet 3.0 support is available we could
> utilize an @Atmosphere annotation on the
> class that extends Application. This would be a meta-annotated
> with an annotation that declares the
> servlet in 2) to be used.
>
> 5) A provider mechanism to initiate ResourceConfig.
>
> Do you need/want help with this one? I must confess not to know how
> Jersey currently handles Provider discovery, but I'd like to do/
> participate in doing a PoC.
Thanks for the offer, this one should be reasonable simple :-)
The following can be placed at line 562 in WebApplicationImpl:
for (ResourceConfigThingy rct :
providersServices.getProviders(ResourceConfigThingy.class) {
rct.configure(resourceConfig);
}
this code should be performed after the ResourceConfig instance has
been obtained but before it is validated. Of course the
ResourceConfigThingy classes or singletons need to be registered in
the ResourceConfig (which at first seems a little odd).
Want to give that a try?
Paul
>
>
> Paul.
>
> On Sep 24, 2009, at 5:28 PM, Paul Sandoz wrote:
>
>> On Sep 24, 2009, at 4:58 PM, Jeanfrancois Arcand wrote:
>>>>>
>>>>> Any solutions will works. Right now Atmosphere uses the
>>>>> ServletContainer but that may change since we have discussed the
>>>>> possibility of running Atmosphere on top of Jersey instead of
>>>>> Jersey on top of Atmosphere.
>>>>>
>>>> Ah! topsy turvy :-) why?
>>>
>>> You didn't want to be able to support some annotation here instead
>>> of having to define Atmosphere in web.xml? I was under the
>>> impression that we discussed something like @Atmosphere support,
>>> but here :-)
>>>
>>
>> OK, i got it now. It was not clear to me that required Atmosphere
>> on top of Jersey, but i see what you mean.
>>
>> IIRC the initial thought was can the number of XML configuration
>> files be reduced to just the web.xml for web deployments.
>>
>> The annotation occurred to me if there was a class that extends
>> javax.ws.rs.core.Application that it could be annotated with
>> something like @Atmosphere. Thus, if using Servlet 3.0 one does not
>> require a web.xml.
>>
>>
>>
>>>>>
>>>>>> If so i think Victor's solution of a ResourceConfigTransformer
>>>>>> (as sent on the atmosphere list, see attached) seems like a
>>>>>> good solution.
>>>>>
>>>>> +1
>>>>>
>>>> Could you log the issue if not already, i don't recall if you
>>>> did, but i am in the process of sensory information overload at
>>>> the moment.
>>>
>>> Done.
>>>
>>
>> Thanks,
>> Paul.
>
>
>
>
> --
> Viktor Klang
>
> Blog: klangism.blogspot.com
> Twttr: viktorklang
>
> Lift Committer - liftweb.com
> AKKA Committer - akkasource.org
> Cassidy - github.com/viktorklang/Cassidy.git
> SoftPub founder: http://groups.google.com/group/softpub