________________________________
From: Bill Burke <bburke_at_redhat.com>
To: jsr339-experts_at_jax-rs-spec.java.net
Sent: Friday, December 9, 2011 6:12 AM
Subject: [jax-rs-spec users] [jsr339-experts] Re: New to the group - comments on the current draft
On 12/8/11 5:33 PM, Sastry Malladi wrote:
> Handlers and filters
>
> * At the first glance, this seems to be confusing as well as
> incomplete. Disclaimer : it is possible that I didn't understand
> this fully
This might illustrate our thoughts on filters/handlers:
http://bill.burkecentral.com/2011/05/24/interceptors-in-jax-rs-2-0/
Sastry > Thanks for the link. I understand the reasoning for having filters and handlers. My point was that could we not have used similar interfaces for both of them, and also the way the spec currently defines Handlers, they really could be called "EntityFilters" - The defined handlers are not really generic.
> * The scenario that is not covered is handlers for wrapping around
> resource method invocation - This is needed, for example, to measure
> the time taken by the resource method itself (monitoring/metrics).
Use EJB or CDI or Spring for this. IMO we should not be duplicating other component models.
Sastry > Perhaps I didn't explain it clear enough - The use case is, when people develop jax-rs resources and deploy them in a container (doesn't matter what container it is) in an organization, the developers expect certain metrics to be captured, without the developers putting any annotations in their code - The operating environment can not depend on the mercy of resource developers adding certain annotations in their code - This should be transparent to each of the resource developers, just like LoggingFilters. How do we do that in the absence of JAX-RS specified Handlers that an environment can install ?
> * Binding : The binding methods described are flexible, but in
> reality, only GlobalBinding is what is used in an operational
> environment.
Maybe this is true with eBay, but...the idea is to be able to bind a behavior to an annotation.
> However, specific resources may indicate that certain
> filters don't apply to them - For example a SecurityFilter is always
> globally configured in an environment and some resource may
> specifically say,
Depends what the security filter is doing. Again, it could be triggered by applying an annotation.
Sastry > I don't think, with the current proposal, you can achieve a use case where "SecurityFilter is globally bound for all resources by default, but specific resources may override that behavior" - The SecurityFilter in my example, is responsible for taking the incoming credentials (e.g OAuth tokens) and authenticating the user and vertifying the authorizations, before proceeding. - But some resources (e.g search related resources) may not need/opt for security and will want to override.
-- Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com