On Apr 27, 2012, at 12:35 AM, Bill Burke wrote:
>
>
> On 4/26/12 8:29 AM, Marek Potociar wrote:
>
>> * /Example 2: Interceptors interfere with filters reading/writing
>> entity - asymmetrical configuration/
>>
>>
>> Suppose a filter wants to replace an entity using writeEntity
>> method. Suppose a special (inbound) reader interceptor is configured
>> in the interceptor chain (e.g. signature verifier), but there is no
>> (outbound) writer interceptor counterpart (e.g. signature appender).
>> How do we guarantee that the entity written by the filter will be
>> readable again? Note that not having a corresponding outbound
>> (signature appender) interceptor configured for the request is a
>> valid and justifiable use case. Even worse, the corresponding
>> outbound functionality can be, in general, provided by an outbound
>> filter instead of an interceptor, which will obviously not get
>> invoked as part of the writeEntity method.
>>
>
>
> I forgot to address this example specifically in my previous responses.
>
> * I don't see how removing MBR/MBW Interceptors (via Option #2) would solve the problem shown in example #2. The only way to solve this problem in either model is for the guilty Filter to have specific knowledge about the Filter chain. BAD FILTER DESIGN!
Well, having no interceptors would mean that filters do not need to count on a potential asymmetrical reader/writer interceptor chain configurations that would prevent from safely reading the entity and then writing back a new or a modified one. Because that's the main problem I am trying to point out - filters may be correctly designed, but may still unintentionally cause that the written entity will not be readable again, due to the way the interceptor chain is configured.
>
> * Is there a specific use case where a filter would want to replace the entity of a Server-side request? Maybe writeEntity() should be removed from ContainerRequestFilterContext and ClientResponseFilterContext?
E.g. conversion between an object graph and a structural links in the entity. But there are many others that we may not even be aware of. I can remember that we added a "writeEntity" concept into Jersey filters based on some user requests., so -1 for removing the read/write methods from filters.
...also, if there are no interceptors, then all interceptor use cases may be transformed into filters, of course.
>
> * Isn't there a similar problem in the Servlet specification? A Filter could call HttpServletRequest.getParameter() which wipes out the InputStream. Which points to again, isn't this just really bad Filter design?
Again, your example shows that you can corrupt entity in a filter, if you are doing stupid stuff. What I am saying is that with interceptors in play, you can corrupt entity in a filter even if you are not doing anything bad.
>
> * With Option #2, what if you needed some functionality that a filter provided when you called writeEntity() on the server side? If you ditched WriterInterceptors and keep writeEntity(), how could you call writeEntity() and have a compressed, header-signed, encrypted message body?
The entityStream is exposed in the filters. It can be wrapped in the same way it would be wrapped by an interceptor. IOW, encoding and decoding is perfectly implementable by request and response filters. The binding priority of the filters would ensure the transport filters are invoked at appropriate point in the filter chain (that concept is not new and is currently used for both, filters and interceptors).
Marek
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com