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!
* 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?
* 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?
* 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?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com