jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: [jax-rs-spec users] Re: Re: Re: HEADS-UP, IMPORTANT: Problems with JAX-RS interceptors

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Fri, 11 May 2012 17:15:53 +0200

On May 11, 2012, at 4:15 PM, Bill Burke wrote:

> On 5/11/12 7:31 AM, Marek Potociar wrote:
>>> Absolutely not. Annotations triggering interception is really useful (just see CDI). Resteasy has a number of filters/interceptors triggered by annotations applied to resource methods.
>>
>> Ok. I thought this would be a hard one. :)
>> I could say that in Jersey we don't have any interceptors and still are able to cover all the features. But I'm not sure I want to argue about this one over and over again. So I'll just give up on this one. If others don't object then we can focus on resolving #2 and we'll be ready to release the next EDR.
>>
>
> FWIW, interceptors evolved from Resteasy when I was implementing various features. They didn't exist at the start and only appeared when they were needed. A side effect was it created some measure of usability.
>
> Now, I don't mind revisiting whether to remove interceptors or not, if we discuss how the various use cases I presented could be implemented without them. This is much different than arguing to remove interceptors because they conflict with some edge case.

All right - but you asked for it :)

Note that I am not questioning interceptors as such here. I am merely questioning the need for name-bound interceptors. Unless I missed something, here is the summary of the use cases you provided to support interceptors:

stream manipulations (encoding/decoding, encryption/decryption)
entity manipulation (structural links resolution/substitution/injection, entity enveloping)
client-side caching

None of the above use cases requires the interceptors to be name-bound. Correct?

Then there was one additional use case I can recall about signature verification where we agreed in the end that filters would be a more suitable for the solution. So I am still missing the use case that would demonstrate usefulness of supporting the name-bound interceptors. That's why I wrote earlier that I'm not convinced we need name-bound interceptors. If you have some undiscussed use cases that would clearly demonstrate we need the feature, please share.

>>>> 2. in pre-matching filters the readEntity() creates and invokes
>>>> interceptor chain based on (any?) annotations passed to the method
>>>
>>> +1.
>>>
>>>> * still not sure here what is the proposed mechanism / API to
>>>> allow the interceptor chain assembly
>>>
>>> Not sure what you mean.
>>
>> How do I assembly the interceptor chain (using JAX-RS API) based on the annotations passed into the readEntity(...) method?
>>
>
> I guess I don't understand why you need to assemble it? Isn't this an implementation detail of the JAX-RS provider?

Taking back. I just thought that you suggest to use different interceptor chains based on the annotations.

>
>> Or do you mean that in pre-matching phase I would take all the global interceptors, add them into chain and let them decide based on the annotations and other data exposed via context what to do
>
> yes

Ok, understood.

>
>
>> and then in post-matching phase I'd add the bound interceptors to the chain and again let the interceptors decide what to do based on the annotations and other data exposed via context?
>
>
> I don't know. Maybe for all filters readEntity() applies global interceptors only and "decides based on the annotations and other data exposed via context what to do?"
>
> No bound interceptors for readEntity() in filters? Does that make it simpler?

Yes, it certainly does. I can't see any issues with such solution at the moment.

> Filters should call bufferEntity() to be safe.

Yes, provided they do invoke readEntity at some point and don't set a new input stream later.

> Actually, this should be reflected in the Javadoc of readEntity(), IMO. That readEntity() consumes the input stream and that to be safe, filter implementations should call buffer entiy.

Sure thing.

Marek

>
> Bill
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com