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.
* 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).
[jsr339-experts] Re: HEADS-UP, IMPORTANT: Problems with JAX-RS interceptors
[jsr339-experts] Re: [jax-rs-spec users] Re: HEADS-UP, IMPORTANT: Problems with JAX-RS interceptors