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
>