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