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.
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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com