jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: [jax-rs-spec users] Re: Heads Up: Severe problem when rewriting responses! Is our Filter API suitable?

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Thu, 11 Oct 2012 23:03:58 +0200

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