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.
attached mail follows:
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