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