On 4/27/12 7:11 AM, Marek Potociar wrote:
> 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.
>
How so? Your example is a PreMatch filter that calls writeEntity() and
a name-bound signature verification. Remove interceptors and you still
have a PreMatch filter that calls writeEntity() and a name-bound
signature verification *Filter* that expects the entity to be signed.
Nothing solved here.
>>
>> * 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).
>
* You have your Example #2 which you have not convinced me would
disappear if you interceptors were ditched.
* You have my client caching example which shows that filtering and
interception work well together, and quite honestly, I don't see how you
could do it with filters-only.
* Resteasy has proven that interceptor re-use between client and server
is a reality.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com