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
>