On Oct 24, 2012, at 11:43 AM, Jan Algermissen wrote:
>
> On Oct 24, 2012, at 4:42 PM, Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com> wrote:
>
>>
>> On Oct 24, 2012, at 6:29 AM, Jan Algermissen wrote:
>>
>>>
>>> On Oct 24, 2012, at 10:11 AM, Jan Algermissen <jan.algermissen_at_nordsc.com> wrote:
>>>
>>>>> JAX-RS entity interceptors are not method interceptors, they are part of the JAX-RS processing pipeline. For method interceptors, use CDI.
>>>>
>>>> Does that apply to injection vie @Context Providers.. , too? Is ist also desired behavior that interceptors are also not called when JAX-RS injection is used?
>>>
>>> FYI:
>>>
>>> Just tried in latest Glassfish.
>>>
>>> The interceptors are not invoked.
>>
>> I'll clarify this in the spec, these are intended to be extension points of the JAX-RS processing pipeline; applications calling readFrom() or writeTo() directly will not trigger interceptor chains.
>
> Fair enough :-)
>
> However, I still fail to see what interceptors can do that filers can't. Why do we need them?
Here are some of the differences:
(i) Clearly they are in different extension points in the pipeline
(ii) Interceptors are wrapping and can access the entity in marshalled and unmarshalled forms
(iii) ReaderInterceptors, just like MBRs, are called only if needed (based on application logic, for example, when Response.getEntity() is called on the client)
In a nutshell, they are there to extend/modify the functionality of MBRs and MBWs.
-- Santiago