Hi Craig,
Thanks for pointing that out. Under those circumstances i really don't
want to duplicate EE 6 functonality and would instead prefer to defer
to it.
Paul.
On Oct 17, 2008, at 7:53 PM, Craig McClanahan wrote:
> Paul Sandoz wrote:
>>
>> On Oct 16, 2008, at 6:50 PM, Craig Iverson wrote:
>>
>>> First let me thank you for all the good work you guys are doing
>>> with jersey and jsr-311. It's been a pleasure to develop against.
>>
>> Thanks!
>>
>>
>>>
>>> I have a feature request that I can add to the issue tracker if
>>> you agree.
>>
>> Please. No need to ask permission to log issues :-)
>>
>>
>>> I think it would be great to be able to configure a filter per
>>> resource(s). In my case its even more than that, it would be
>>> more beneficial to also support an exclude list. I have a case
>>> where I only want certain filters applied to certain resources. I
>>> really want a couple of filters to always be applied except for on
>>> a couple of resources. The reason for the exclude list would
>>> allow other team members to add resources without worrying about
>>> configuring the filter for the new resource. Your thoughts?
>>
>> Currently request and response filters are called before resource
>> matching is performed. Having filters apply to specific root
>> resource classes could also make sense, but i wonder if the exclude
>> list complicates matters, especially if there is more then one
>> filter present in the filter chain, rather than being explicit and
>> describing the list of resources with the list of filters e.g.
>>
>> Map<List<Class<??>, List<ContainerRequestFilter>>
>>
>> I am wondering if it is appropriate to have filters associated with
>> resources and resource methods configured from the resources
>> themselves. How about allowing the following:
>>
>> @RequestFilters({A.class, B.class})
>> @Path("resource")
>> public class Resource {
>>
>> @RequestFilters({C.class, D.class})
>> @GET
>> public String get() { ... }
>>
>> @RequestFilters({E.class, F.class})
>> @Path("sub-resource")
>> public Object getSubResource() { ... }
>> }
>>
> Just as a comparison point, this is conceptually pretty similar to
> how you can define interceptors on EJB session beans in the bean
> classes themselves:
>
> @Stateless
> // Class level interceptors around all method calls
> @Interceptors({TracingInterceptor.class})
> public class MySessionBean {
>
> // Method level interceptors around calls to this method
> @Interceptors({SomeInterceptor.class, AnotherInterceptor.class})
> public String result(String arg1, String arg2) {
> ... business logic goes here ...
> }
>
> }
>
> There are also some additional ideas in EJB interceptors that might
> be worth emulating:
>
> * @ExcludeClassInterceptors and @ExcludeDefaultInterceptors
> to turn off normal interceptors for a particular class or method.
>
> * @AroundInvoke to let you specify the logic of a class interceptor
> inline in the same class, rather than requiring it to be separate.
>
> Of course, once you get into a world of multiple layers of
> interceptors, the invocation order needs to be clearly defined as
> well.
>
> Craig
>
>
>> Paul.
>>
>>>
>>> Craig
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>