> > 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.
I know I can use a wrapper to *capture* the entity representation that way,
but what is that good for in something called "filter" (in the sense of a
device that has an input and an output and applies rules what to pass) if it
cannot *modify* the outgoing entity? If one can solely log the original
entity representation but cannot modify it, I think we should not name that
thing "filter" but "listener". Essentially it looks like people looking for
real "filter" capabilities should start with implementing an interceptor and
use filters only for that things interceptors cannot provide. At least this
seems to work better for the filters I did in the past days.
Thanks!
Markus