On 05/03/13 14:39, Santiago Pericas-Geertsen wrote:
>
> On Mar 5, 2013, at 6:48 AM, Sergey Beryozkin<sberyozkin_at_talend.com> 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
@PreMatching
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
>