On Mon, Sep 28, 2009 at 9:45 AM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
> 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?
>
Sure! I'll tinker with it during the week :)
Thanks for the heads up!
>
> 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
>
>
>
--
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