On Apr 27, 2012, at 5:59 PM, Bill Burke wrote:
>>> b) We should investigate the behavior of calling write/readEntity within a filter.
>>>
>>> c) Maybe writeEntity within PreProcessing should create its own interceptor chain based on the type and annotation[] array passed into it?
>>>
>>> d) Maybe readEntity() should automatically buffer the request?
>>>
>>> e) Maybe methods on ContainerRequestContext should be added like wasBuffered(), wasRead() etc., then other interceptors will know that a read/write/buffering happened?
>>
>> I like interceptors in general, but I'm still worried about the complex interactions between them and the filters. The questions above touch in all the thorny points. If we can't explain the interaction between filters and interceptors in a few sentences, and with the help multiple new methods, then there's a problem IMO.
>>
>
> What are the other specific complexities in the interaction between filters and interceptors?
I still have some concerns about c) on your list above. The writer interceptor chain is really configured to produce a _response_ entity, not a new _request_ entity. I think there's a fundamental mismatch here that goes beyond the correctly-written filter discussion.
I had originally thought there should be an implicit invariant stating that a filter should be able to read an entity it writes, but this is likely too strong a requirement on an application (given that interceptor chains are used by both filters and resources).
Still catching up on some e-mail, but at this point, I still have some concerns about writeEntity() and interceptors.
-- Santiago