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