On Oct 11, 2012, at 11:53 PM, Markus KARG <markus_at_headcrashing.eu> wrote:
> Jan,
>
> great to hear from you. :-)
>
>>> the problem is that the response filter (or an interceptor, or a
>>> combination
>>> - I actually don't care as long as it works) must change the entity
>>> *representation* (the XML, not the Java Object).
>>
>> Why don't you do everything in an interceptor?
>>
>> Jan
>
> Good point. In fact, just a minute ago I made it work to overwrite the
> Content-Length by setting the header in the write interceptor. But to answer
> your question: I still need the request filter and the custom property to
> decide whether the interceptor must work, since there is one more constraint
> I did not repeat to say (was contained in the very first posting of this
> thread): I have to modify the http method before matching, which is
> impossible in an interceptor.
>
> Anyways, the filter is working so, so it proofs that the API is suitable. On
> the other hand, it would be interesting to learn what response context's
> setOutputStream() method actually is good for...?
If you wrap the output stream returned by getOutputStream(), you need to be able to set the wrapped output stream back, right? That's what the setter is there for.
>
> Regards
> Markus
>
>