On Nov 1, 2011, at 12:45 PM, Markus KARG wrote:
> For the sake of completeness and flexibility I would say: Yes.
>
> Currently I actually do not have a real use case for that as all OUR filters
> only deal with entity content, but in fact, the filters we are applying
> currently ARE pre-matching ones, as they are implemented as ServletFilters.
> So I could imagine that "out there" some filters will exists, which do what
> you describe. So why not doing it?
Right, I'll share a proposal on how to support these in a few days. The main idea hinges on supporting a new type of binding for them.
-- Santiago
>
>> -----Original Message-----
>> From: Santiago Pericas-Geertsen
>> [mailto:Santiago.PericasGeertsen_at_oracle.com]
>> Sent: Dienstag, 25. Oktober 2011 21:55
>> To: jsr339-experts_at_jax-rs-spec.java.net
>> Subject: [jsr339-experts] Pre-Matching Filters?
>>
>> Hello Experts,
>>
>> As you know, we already support filters as well as a few different
>> ways in which they can be bound to resource classes and methods (by
>> name or global/static or dynamic). However, all these filters are
>> intended to be executed _after_ requests are matched to resource
>> methods.
>>
>> There are some use cases in which requests need to be transformed
>> _before_ the matching algorithm kicks off. An example of this is a
>> filter that overrides the HTTP method, e.g. using X-HTTP-Method-
>> Override. In a servlet environment, this could be achieved by using a
>> servlet filter. But, of course, JAX-RS runs on many other environments.
>>
>> Should we look at supporting these type of pre-matching
>> filters/transformers/routers? (Clearly, I don't have a good name for
>> them yet).
>>
>> -- Santiago
>>
>>
>