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