Salut,
Paul Sandoz wrote:
>
> On Sep 23, 2009, at 5:37 PM, Jeanfrancois Arcand wrote:
>
>> Salut,
>>
>> Paul Sandoz 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)?
>>
>> 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 :-)
>
>>
>>> 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.
A+
-- Jeanfrancois
>
> Paul.
>
>
>>> addition we would need to improve the ResourceConfig support for the
>>> setting of filters, as filters may also have been declared by the user.
>>
>> Thanks!
>>
>> -- Jeanfrancois
>>
>>
>>> Paul.
>>> ------------------------------------------------------------------------
>>> Subject:
>>> Re: [Fwd: [Jersey] Programmatic API for configuring Jersey's
>>> ServletContainer]
>>> From:
>>> Viktor Klang <viktor.klang_at_gmail.com>
>>> Date:
>>> Wed, 23 Sep 2009 11:41:20 +0200
>>> To:
>>> users_at_atmosphere.dev.java.net
>>> To:
>>> users_at_atmosphere.dev.java.net
>>> On Wed, Sep 23, 2009 at 11:28 AM, Paul Sandoz <Paul.Sandoz_at_sun.com
>>> <mailto: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
>>> <mailto:users-unsubscribe_at_atmosphere.dev.java.net>
>>> For additional commands, e-mail: users-help_at_atmosphere.dev.java.net
>>> <mailto:users-help_at_atmosphere.dev.java.net>
>>> --
>>> Viktor Klang
>>> Blog: klangism.blogspot.com <http://klangism.blogspot.com>
>>> Twttr: viktorklang
>>> Lift Committer - liftweb.com <http://liftweb.com>
>>> AKKA Committer - akkasource.org <http://akkasource.org>
>>> Cassidy - github.com/viktorklang/Cassidy.git
>>> <http://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
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>