Skip to main content

[jsr339-experts] Re: HEADS-UP, IMPORTANT: Problems with JAX-RS interceptors

  • From: Bill Burke <bburke@...>
  • To: jsr339-experts@...
  • Subject: [jsr339-experts] Re: HEADS-UP, IMPORTANT: Problems with JAX-RS interceptors
  • Date: Thu, 26 Apr 2012 18:35:56 -0400



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


[jsr339-experts] HEADS-UP, IMPORTANT: Problems with JAX-RS interceptors

Marek Potociar 04/26/2012

[jsr339-experts] Re: HEADS-UP, IMPORTANT: Problems with JAX-RS interceptors

Sergey Beryozkin 04/26/2012

[jsr339-experts] Re: HEADS-UP, IMPORTANT: Problems with JAX-RS interceptors

Bill Burke 04/26/2012

[jsr339-experts] Example 3: Why current ReaderInterceptors are cool.

Bill Burke 04/26/2012

[jsr339-experts] Re: Example 3: Why current ReaderInterceptors are cool.

Sergey Beryozkin 04/27/2012

[jsr339-experts] Re: Example 3: Why current ReaderInterceptors are cool.

Sergey Beryozkin 04/27/2012

[jsr339-experts] Re: Example 3: Why current ReaderInterceptors are cool.

Bill Burke 04/27/2012

[jsr339-experts] Re: Example 3: Why current ReaderInterceptors are cool.

Sergey Beryozkin 04/27/2012

[jsr339-experts] Re: Example 3: Why current ReaderInterceptors are cool.

Bill Burke 04/27/2012

[jsr339-experts] Re: Example 3: Why current ReaderInterceptors are cool.

Marek Potociar 04/27/2012

[jsr339-experts] Re: HEADS-UP, IMPORTANT: Problems with JAX-RS interceptors

Bill Burke 04/26/2012

[jsr339-experts] Re: [jax-rs-spec users] Re: HEADS-UP, IMPORTANT: Problems with JAX-RS interceptors

Marek Potociar 04/27/2012

[jsr339-experts] Re: [jax-rs-spec users] Re: HEADS-UP, IMPORTANT: Problems with JAX-RS interceptors

Bill Burke 04/27/2012
 
 
Close
loading
Please Confirm
Close