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.
>
> Does anybody find this strange? This is just one of the many reasons I can't stand the builder pattern. If you could
> just modify the request directly via setter methods, it would all be much simpler instead of having all these weird
> in-between states, complex interfaces and interaction patterns.
>
> i.e.
>
> Wouldn't it look much nicer to do:
>
> ctx.getRequest().accept("application/xml").redirect("....");
>
> Instead of:
>
> Request request = ctx.getRequest().copy()
> .accept("applicatoin/xml")
> .redirect("...").build();
> ctx.setRequest(request);
>
> I know I'm complaining to deaf ears on this, but it just bothers the hell out of me.
Mutable request idea does not play well with the response/response builder pair that exists in JAX-RS 1.x already.
One possible solution might be to return a request builder representing the "real" request from the getRequest()
instead. I am however afraid of potential concurrency issues in some more complex filter scenarios.
Marek
>
>