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