users@jax-rs-spec.java.net

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

From: Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com>
Date: Wed, 6 Mar 2013 11:20:57 -0500

Sergey,
 
 Please file a JIRA and I'll add a sentence to the spec disallowing this form of "mixed" binding. I can't think of a use case, so it's better to update the spec IMO.

 Thx.

-- Santiago

On Mar 6, 2013, at 8:28 AM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:

> On 05/03/13 22:45, Sergey Beryozkin wrote:
>> 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 ?
>>
>
> Well, after struggling a bit I made it work but it was not easy; I have a couple of questions still, but, as far as the original question is concerned,
>
> >>> @PreMatching
> >>> @A
> >>> public class MyFilter implements ContainerRequestFiler {
> >>> }
>
> should the above work or not; I've no particular case in mind right now, I thought the above might help in our Cors filter migration, but the above won't help the implementation if it is pre-match call or not, unless may be if the injected ResourceInfo provides the hints, so probably does not make sense to allow for the above combination ?
>
> Thanks, Sergey