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
> 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