dev@jersey.java.net

Re: [Jersey] Programmatic API for configuring Jersey's ServletContainer

From: Viktor Klang <viktor.klang_at_gmail.com>
Date: Mon, 28 Sep 2009 21:18:24 +0200

Hehe, I guess Paul was right, (unsurprisingly so)

it should be enough with the following patches applied to jersey-server

What do you think, guys?



On Mon, Sep 28, 2009 at 9:49 AM, Viktor Klang <viktor.klang_at_gmail.com>wrote:

>
>
> 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
>



-- 
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