I hear you. But I just didn't had the problem before so I cannot judge for
myself whether this is so important that JAX-RS 2.0 must support it, while
e. g. Servlet Filters do not. Actually, I never thought of "filtering
targets", I always thought of (and applied) "filtering requests". So it
never came into my mind to get information of the target. But I see your
point and it looks interesting.
> -----Original Message-----
> From: Bill Burke [mailto:bburke_at_redhat.com]
> Sent: Montag, 14. November 2011 15:02
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: Proposal for Pre-
> Match Filters
>
> I'll repeat myself, but you may want to pass in configuration
> information via anntations attached to the method, field, or method
> param. For example, an authorization mechanism may want to extract
> permissions from an annotation applied to a method.
>
> Really this is the same reason MessageBodyReader/Writers need access to
> annotation information.
>
> On 11/12/11 11:53 AM, Markus KARG wrote:
> > What do you mean with "thing"? Why are Request and Response not
> enough?
> >
> >> -----Original Message-----
> >> From: Bill Burke [mailto:bburke_at_redhat.com]
> >> Sent: Samstag, 12. November 2011 01:07
> >> To: jsr339-experts_at_jax-rs-spec.java.net
> >> Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: Proposal for
> >> Pre- Match Filters
> >>
> >> Your proposal sounds interesting Markus, but you need to be able to
> >> get information about the thing you are filtering. i.e. annotations
> >> applied to the target you are filtering. Really you need the same
> >> information passed into a MessageBodyReader/Writer.
> >>
> >> On 11/11/11 2:20 PM, Markus KARG wrote:
> >>> Actually I wonder whether it makes sense to have different filters
> >> for
> >>> Request and Response, as both are directly related. From the user's
> >>> view, it looks much more friendly to have:
> >>>
> >>> @When(PreMatching)
> >>>
> >>> class MyFilter {
> >>>
> >>> void filter(Request, Response) {
> >>>
> >>> .
> >>>
> >>> }
> >>>
> >>> }
> >>>
> >>> See, I look at it from the user's view, not from the API
> designer's.
> >>> The above looks most natural to me from this perspective. In
> >> contrast,
> >>> your proposal induces a lot specs to read to understand what the
> two
> >>> different methods actually mean.
> >>>
> >>> Regards
> >>>
> >>> Markus
> >>>
> >>> *From:*Santiago Pericas-Geertsen
> >>> [mailto:Santiago.PericasGeertsen_at_oracle.com]
> >>> *Sent:* Dienstag, 8. November 2011 20:08
> >>> *To:* jsr339-experts_at_jax-rs-spec.java.net
> >>> *Subject:* [jsr339-experts] Re: [jax-rs-spec users] Re: Proposal
> for
> >>> Pre-Match Filters
> >>>
> >>> Markus,
> >>>
> >>> Glad you bring this is up, because this is basically how we started
> >>> before switching to the interface approach. Let me try to explain
> >> why:
> >>>
> >>> 1) We have a 1:1 correspondence between extension points (code
> >>> points in
> >>> AOP) and interfaces. For example, the extension points Pre and Post
> >>> and the interfaces RequestFilter and ResponseFilter. Other 1.X
> >>> extension points are MBR, MBW, etc. All providers in JAX-RS are
> >>> identified by the interface they implement, not an annotation
> >> (besides
> >>> @Provider). Using an annotation for pre-match (i.e. to move the
> >>> extension point from pre to pre-match) breaks this rule.
> >>>
> >>> 2) Annotations decorate classes but classes can implement multiple
> >>> extension points. For example:
> >>>
> >>> @When(Before)
> >>>
> >>> class LoggingFilter implements RequestFilter, ResponseFilter { . }
> >>>
> >>> The annotation in the example above only applies to the
> >> RequestFilter:
> >>> there is no such thing as a pre response filter. Having a dedicated
> >>> interface like for all other extension points makes it less
> >> confusing,
> >>> and better follows the existing JAX-RS model as described in (1).
> >>>
> >>> -- Santiago
> >>>
> >>> On Nov 8, 2011, at 1:03 PM, Markus KARG wrote:
> >>>
> >>>
> >>>
> >>> As preFilter and preMatchFilter share the same signature, I wonder
> >> why
> >>> we need two different names? This assumes that it shall be possible
> >> to
> >>> write one filter class that serves both ways. But is this
> realistic?
> >> I
> >>> think not. I assume a filter is either pre or post, not both. So I
> >>> think it would be more natural to have just one method, that by
> >>> default is non-pre-match, and if one wants to make it pre-match,
> >>> give it an annotation to change the extension point. In one thinks
> >>> he actually must serve both ways, he could just add another
> >>> extension
> >> point. Example:
> >>>
> >>> @When({Before, After})
> >>>
> >>> filter(ctx) {}
> >>>
> >>> That way it looks more like triggers in SQL that also can be timed
> >>> with BEFORE and AFTER without changing the common declaration
> syntax
> >>> or renaming them.
> >>>
> >>> Regards
> >>>
> >>> Markus
> >>>
> >>> *From:*Santiago Pericas-Geertsen
> >>> [mailto:Santiago.PericasGeertsen_at_oracle.com]
> >>> *Sent:*Dienstag, 8. November 2011 17:52
> >>> *To:*jsr339-experts_at_jax-rs-spec.java.net
> >>> <mailto:jsr339-experts_at_jax-rs-spec.java.net>
> >>> *Subject:*[jsr339-experts] Proposal for Pre-Match Filters
> >>>
> >>> Hello Experts,
> >>>
> >>> A new proposal to support pre-match filters is ready for review
> [1].
> >>> The wiki includes a couple of other minor changes to simplify the
> >> API.
> >>> Namely, making @GlobalBinding the default (and dropping it) as well
> >> as
> >>> a new injectable type ResourceInfo.
> >>>
> >>> -- Santiago
> >>>
> >>> [1] http://java.net/projects/jax-rs-spec/pages/PreMatchingFilters
> >>>
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com