On 2/24/12 8:30 AM, Marek Potociar wrote:
>
>
> On 02/23/2012 07:21 PM, Bill Burke wrote:
>> Consider this RequestFilter that modifies the request on the server side:
>>
>> {
>> ...
>> RequestBuilder builder = ctx.getRequest().copy();
>> builder.accept("application/xml").redirect("http://.../foo/bar/blah");
>> Request request = builder.build();
>> request.readEntity(Foo.class);
>> ctx.setRequest(request);
>>
>> }
>>
>> As it stands now, this code is perfectly legal. The weird part is that readEntity() can be invoked before the "real"
>> request is changed. Headers aren't updated for the "real" request until ctx.setRequest() is called.
>
> That's one of the reasons why I fought so much for returning a "next action" that would contain the (next) "real"
> request or response from a filter. To me, the current programming model is very error-prone. Sadly, I was voted down.
>
I don't see what "next action" has anything to do with this issue.
"Next action" deals with aborting a request, not modifying a request or
response.
> Mutable request idea does not play well with the response/response builder pair that exists in JAX-RS 1.x already.
>
Well, things have changed since then. The idea of modifying a
request/response before and after its on the wire via
Interceptors/Filters didn't exist then.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com