[jax-rs-spec users] [jsr339-experts] Re: Single ContainerRequestFilter in pre-match and post-match mode ?

From: Sergey Beryozkin <>
Date: Tue, 5 Mar 2013 22:45:45 +0000

On 05/03/13 14:39, Santiago Pericas-Geertsen wrote:
> On Mar 5, 2013, at 6:48 AM, Sergey Beryozkin<> wrote:
>> Hi
>> Is it valid to have
>> @PreMatch
>> @A
>> public class MyFilter implements ContainerRequestFiler {
>> }
>> where @A would bind MyFilter to some resource (method) in a post-match phase ?
>> Or does @PreMatch means that MyFilter can only ever be executed in a pre-match phase ?
> I don't think the spec states anything about this particular combination. In a way, it's a bit contradictory in the sense the @PreMatching implies globally bound and @A implies locally bound.
> Do we want to say something about it or leave it as is?
I have difficulties porting some of CXF filters to ContainerRequestFilter.
Specific case:

CORS filter, needs to handle a pre-flight request (OPTIONS), without
getting a resource match done (PRE-MATCH) and also matched requests
(simple requests, etc), POST-MATCH mode

For example, at the moment, I write

class CorsFilter implements ContainerRequestFilter,
ContainerResponseFilter {}

This fails a test where this filter needs to handle pre-flight requests
(pre-match OPTIONS). I figured eventually that

class CorsFilter implements ContainerRequestFilter,
ContainerResponseFilter {}

fixes that test but next it fails all other test involving requests
which can actually be matched.

Any idea on how to handle it ?

I wonder - should we have

PreMatchContainerRequestFilter instead of relying on @PreMatching ?

Cheers, Sergey

> -- Santiago