Sorry if my problem was not described clearly enough already from the start.
Please see my answer to Bill's question to see why I cannot solve this task
with the current draft of the API.
> -----Original Message-----
> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
> Sent: Donnerstag, 11. Oktober 2012 23:04
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: Heads Up: Severe
> problem when rewriting responses! Is our Filter API suitable?
>
> Hi Markus,
>
> I share Bill's reservations. In the container response filter you have
> access to the object entity as it was set by the resource method. So
> you can do whatever you want with it. Also this object entity is never
> converted into an input stream as it is merely marshalled to the output
> stream, which you can wrap. Perhaps I'm still missing the issue you
> see?
>
> Marek
>
> On Oct 11, 2012, at 9:16 PM, Bill Burke <bburke_at_redhat.com> wrote:
>
> > Markus, in a response filter you can:
> >
> > * change the status
> > * change/add/remove headers
> > * change the Java Object entity (even set it to null)
> >
> > So I don't understand your problem.
> >
> > On 10/11/2012 1:08 PM, Markus KARG wrote:
> >> Ok, so can you provide a code example that will solve the described
> >> problem? Maybe I am just too blind to see how the proposed API shall
> >> work. Thanks.
> >>
> >> BTW, what then is the sense of setting a different output stream in
> a
> >> response? And why CAN I filter on the entity representation in a
> >> REQUEST filter?
> >>
> >> I think the idea of having separate entity interceptors is a good
> >> idea, but not as an alternative to stream filtering of the
> >> representation, but ADDITIONALLY.
> >>
> >> How long the discussion was is not an argument. Only the result
> counts.
> >> And the result is: One can filter request representations, but not
> >> response representations. We checked only three of our filters, and
> >> got only two working. This is not a good result for a proposed API.
> >> So I really ask you for a solution.
> >>
> >> *From:*Santiago Pericas-Geertsen
> >> [mailto:Santiago.PericasGeertsen_at_oracle.com]
> >> *Sent:* Donnerstag, 11. Oktober 2012 15:37
> >> *To:* jsr339-experts_at_jax-rs-spec.java.net
> >> *Subject:* [jsr339-experts] Re: [jax-rs-spec users] Heads Up: Severe
> >> problem when rewriting responses! Is our Filter API suitable?
> >> *Importance:* High
> >>
> >> Markus,
> >>
> >> So the transformation in this use case operates on the entity
> >> representation rather than the entity itself?
> >>
> >> We've had a lot of discussions (see archives) about filters reading
> >> and writing entities (thus, triggering interceptors and MBR/MBW
> >> multiple
> >> times) and that creates all sorts of issues. Hence the reason why
> the
> >> current proposal separates filtering from serialization. I.e., the
> >> current separation is by design.
> >>
> >> -- Santiago
> >>
> >> On Oct 10, 2012, at 4:14 PM, Markus KARG wrote:
> >>
> >>
> >>
> >> Hello Experts,
> >>
> >> to check how well we designed the Filters API in JAX-RS 2.0 we tried
> >> to rewrite some former Servlet Filters into JAX-RS 2.0 filters. It
> >> all looks good so far, but with one filter we have a severe problem
> >> that seems to proof that our API has a severe problem. Maybe we
> >> misunderstood something in the JavaDocs, but currently it looks as
> >> the following is impossible in JAX-RS (what would render the Filter
> API useless for us):
> >>
> >> Scenario: We need to write one PreMatchingFilter that rewrites
> >> EVERTHING, i. e. in a request it replaces the method, the URL, the
> >> headers, and wraps the entity content, and for the same request it
> >> must rewrite the response in a way that the status code, status
> info,
> >> headers are replaced and the entity content is wrapped. Should be
> >> possible, but actually is NOT (or at least looks like it is not):
> >>
> >> In filter(ContainerRequestContext, ContainerResponseContext) we can
> >> invoke setStatusCode, setStatusInfo, etc., but how do we wrap the
> >> original response entity? We see there is a
> >> responseContext.getEntityStream method, but that returns an
> >> OutputStream
> >> -- which we cannot read! So how to get the original content to
> >> analyze and wrap it? See, the entity shall not be replaced by
> >> "anything", but by a variant of the original response entity, so we
> >> need to get that in the filter method!
> >>
> >> And, no, we do not want to provide a separate entity interceptor as
> >> this would induce the need to split the replacement code into two
> >> different methods -- one to replace status and headers, one to
> >> replace the method, which is everything but smart.
> >>
> >> We think that to implement such a complex filter, the
> >> responseContext.getEntityStream() method must return a InputStream
> >> instead of OutputStream, and the setEntityStream() must accept an
> >> InputStream instead of an OutputStream.
> >>
> >> So did we a fault in our sample code, or is there a fault in the
> Filter API?
> >>
> >> Thanks!
> >>
> >> Markus
> >>
> >
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com