I understand your idea, I just don't like the additional complexity it
induces.
> -----Original Message-----
> From: Santiago Pericas-Geertsen
> [mailto:Santiago.PericasGeertsen_at_oracle.com]
> Sent: Montag, 14. November 2011 15:38
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: Re: Proposal for
> Pre-Match Filters
>
>
> On Nov 11, 2011, at 7:07 PM, Bill Burke wrote:
>
> > 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.
>
> In addition to this, I find the separation of request filtering and
> response filtering more intuitive. If I'm only interested in
> authenticating requests, why do I need to care about responses?
> Moreover this separation, as I stated before, seems more inline with
> the separation of MBRs and MBWs from 1.X.
>
> -- Santiago
>
> >
> > 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
> >