On 23/08/12 13:06, Marek Potociar wrote:
>
> On Aug 22, 2012, at 5:59 PM, Bill Burke<bburke_at_redhat.com> wrote:
>
>>
>>
>> On 8/15/2012 5:26 AM, Marek Potociar wrote:
>>> I checked the spec text and I think we should clarify this. But first we
>>> should agree on the general processing flow. Here's the my original idea
>>> about how it should work in various scenarios:
>>>
>>> *Definitions:*
>>>
>>> * pre-matching request filters
>>> o request filters annotated with @PreMatching, container-only
>>> * post-matching/bound request filters
>>> o global request filters (unbound) as well as any req. filters
>>> bound to the matched method, container-only
>>> * pre-matching response filters
>>> o response filters annotated with @PreMatching, container-only
>>> * post-matching/bound response filters
>>> o global response filters (unbound) as well as any response
>>> filters bound to the matched method, container-only
>>>
>>
>> "global" and "resource method bound" response filters should be combined and sorted based on BindingPriority. A Pre matching designation makes sense for request filters as they may change the request before it matches a method. For response filters it doesn't make sense and is even error prone as you may have ordering issues.
>>
>> So, if there was a match, generate a list of respponse filters and writer interceptors based on the resource method match and sort them all based on BindingPriority. If there is an abort/exceptiono in PreMatch request filter, then response filter/writer interceptor lists are generated based on no resource-method match.
>
> I think we're on the same page that it makes sense to have only a single response filter chain. Sorry for the confusion. In my scenarios I just wanted to point out that there are response filters that need to be applied regardless of whether the request was matched or not. I assumed that there may be response filters that have to be applied globally but only if a request was matched. Or are you saying that this distinction between two tastes of "global response filter" is not necessary? If that's the case, I'm fine with that but then I'd say that ALL global filters (request and response) should be invoked regardless of the matching result. IOW, for global request filters it would mean that they would be implicitly invoked before matching. Name-bound and dynamically bound filters would be then invoked only for a particular matched resource method.
>
> Btw. seems to me that dynamically bound global filter that has all the necessary resource-specific initialization properties (e.g. ResourceInfo etc.) pre-computed at deploy time will be anyway more efficient than a global post-matching filter that will need to inject proxied resource information with every request.
>
>>>
>>> *Scenarios:*
>>>
>>
>> Do we need a way to tell a filter that an error happened? Maybe different callbacks?
>
> I know this is not the first time you're asking, but I found the use case presented by your user marginal with an existing work-around. If you insist, we can consider adding following method to ContainerResponseContext:
>
> Throwable getError();
>
> It would return the originating error from which the response was derived (if any) or null (if no error happened).
>
If we already have Response then this method might be redundant, but
probably makes sense as we may have a case where no ExceptionMapper has
been found and the exception is being propagated to the container,
assuming the filter is still invoked in this case ?
>>
>> ContainerResponseFilter {
>>
>> filter(...); // if resource method didn't throw exception
>> applicationException(...);
>> filterException(...);
>> writerException(...);
>> }
>
> I'm against. Why would I force my users implement methods they most likely never need? We have not seen a single use case in Jersey or have not received any user request for Jersey filtering framework that would indicate a need to provide such callback functionality.
>
>>
>> Right now we don't have anything like that. We only run response filters if there was a successful method invocation. Nor do we run filters after Exceptionapper.
>
> That's obviously where my proposal (and current Jersey 2 implementation) differs from yours. I think that response filters should be also run AFTER exception mapping (at least in some cases).
+1, same way in CXF
Sergey
>
>> In all your examples, what I worry about is you have too many scenarios a filter/interceptor developer has to code for.
>
> Why? It may be more complicated for JAX-RS impl. providers to implement, but a response filter developer should merely focus on doing the right thing for the current response. It should not need to care about whether the response is exception-generated or not (perhaps except for few esoteric use cases).
>
>>
>>
>> Maybe this might simplify things?
>>
>> If exception thrown from resource method
>> - ExceptioMapper
>> - response filters and interception if there is an entity.
>>
>> If an exception thrown in response filter (or WriterInterceptor)
>> - ExceptionMapper
>> - no additional filtering or interception.
>
> That's similar to what I'm saying as in the alternative approach - except that I recognize a possibility that some global response filters SHOULD be applied to ANY response. I've seen that Santiago has already replied something, so I'll add more comments to that discussion thread.
>
> Marek
>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>