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();
Request request = builder.build();
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.
Mutable request idea does not play well with the response/response builder
pair that exists in JAX-RS 1.x already.
[jsr339-experts] Re: the weird states of Request on server side