+1 for improving ResourceConfig for adding filters programaticallynothing
dramatic, but current interface of map of properties for bunch of other
stuff as well as resource filters feels unnatural in my opinion.
J
On Wed, Sep 23, 2009 at 2:00 PM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
> On Sep 21, 2009, at 8:30 PM, Jeanfrancois Arcand wrote:
>
>
>>
>> Jae Lee wrote:
>>
>>> try this
>>> WebApplication webApplication = new WebApplicationImpl();
>>> ResourceConfig resourceConfig = new DefaultResourceConfig();
>>> String[] filters = new String[]{"org.atmosphere.core.AtmosphereFilter"};
>>> resourceConfig.getProperties().put(ResourceConfig.PROPERTY_RESOURCE_FILTER_FACTORIES,
>>> filters);
>>> webApplication.initiate(resourceConfig);
>>>
>>
>> Thanks...but in the example above, I don't use the ServletContainer class?
>> Let me dig more..
>>
>>
> Do you want a mechanism that works independently of ServletContainer (and
> more general the HTTP container used)?
>
> If so i think Victor's solution of a ResourceConfigTransformer (as sent on
> the atmosphere list, see attached) seems like a good solution. In addition
> we would need to improve the ResourceConfig support for the setting of
> filters, as filters may also have been declared by the user.
>
> Paul.
>
>
> ---------- Forwarded message ----------
> From: Viktor Klang <viktor.klang_at_gmail.com>
> To: users_at_atmosphere.dev.java.net
> Date: Wed, 23 Sep 2009 11:41:20 +0200
> Subject: Re: [Fwd: [Jersey] Programmatic API for configuring Jersey's
> ServletContainer]
>
>
> On Wed, Sep 23, 2009 at 11:28 AM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
>>
>> On Sep 21, 2009, at 8:40 PM, Jeanfrancois Arcand wrote:
>>
>>
>>>
>>> Viktor Klang wrote:
>>>
>>>> Cool. How about being able to annotate a jersey configuration provider?
>>>> @Provider
>>>> class Conf implements WebApplicationConfiguration
>>>> {
>>>> ...
>>>> }
>>>> What do you think?
>>>>
>>>
>>> Wow I like that one. Let's see what Paul thinks (he is back tomorrow). It
>>> may not work as I'm not sure the Jersey annotation processor can do that
>>> (but I might be wrong).
>>>
>>>
>> The ResourceConfig is currently the place to configure stuff, as that will
>> be independent of any container.
>>
>
>
> Of course, but wouldn't it be beneficial to be able to @Inject
> ResourceConfig
>
> or be able to have something like:
>
> interface ResourceConfigTransformer
> {
> public ResourceConfig transform(@Inject ResourceConfig config);
> }
>
> And then on boot, find all @Provider who's instanceof
> ResourceConfigTransformer, create a DefaultResourceConfig, and then pipeline
> it through all transformers and then pass the result into the WebApplication
>
>
>
>
>
>
>
>
>>
>> I think what we require are specific methods to add filters on
>> ResourceConfig. It is possible to add filters programatically using
>> ResourceConfig but it is problematic because the developer has to manage the
>> different Java types that may be set as the property.
>>
>> Also we need to ensure that any user-defined filters will still be
>> declared if Atmosphere adds it's own.
>>
>> Another solution is to support filters annotated with @Provider, currently
>> i have avoided doing so because order of filters may be important. It should
>> be possible to support "classes" of filter that define ordering groups, but
>> i am not sure about that.
>>
>> I have not yet got around to any solution you may have proposed (way too
>> much email to process email!) so not sure if we are on the same page or
>> not...
>>
>> Paul.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_atmosphere.dev.java.net
>> For additional commands, e-mail: users-help_at_atmosphere.dev.java.net
>>
>>
>
>
> --
> 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
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>