[jax-rs-spec users] [jsr339-experts] Re: the weird states of Request on server side

From: Bill Burke <>
Date: Fri, 24 Feb 2012 15:20:02 -0500

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 =;
>> 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

> 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