Skip to main content

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

  • From: Bill Burke <bburke@...>
  • To: jsr339-experts@...
  • Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: HEADS-UP, IMPORTANT: Problems with JAX-RS interceptors
  • Date: Fri, 27 Apr 2012 10:42:07 -0400



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


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

(continued)

[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