Hey Tatu (coincidentally, just posted to user_at_jackson )
n Sat, Jul 30, 2011 at 6:45 PM, Tatu Saloranta <tsaloranta_at_gmail.com> wrote:
> The way I have done this has been to just define generic wrapper like
>
> abstract class Request<T> {
> public Map<String,Object> headers; // or getters/setters
> public long timestamp;
> public ServiceDefs service;
> public T data;
> }
>
> and using generic type with proper payload type on method signature,
> routing from there as necessary (calling method that handles generic
> info).
>
So I have been trying initially a somewhat similar technique (at least if I
understand well what you mean) where I wanted to make it reasonably
transparent, so I created a class called 'ResponseWrapper' which has
identical factory methods to Response and does the wrapping of the entity.
Works ok, but forces people to use it instead of standard api and thought it
was not that great. The beef of the technique would end up being something
like:
class ResponseWrapper {
........ attributes to wrap around....
Object entity
..... all similar methods to Response ...
public static Response.ResponseBuilder status(Response.Status status,
String message, Object entity) {
........... gather a,b,c,d,e,f ....
return Response.status(status).entity(new
ResponseWrapper(a,b,c,d,e,f, entity));
}
}
Another alternative I was looking, is potentially to inherit jersey's
RuntimeDelegateImpl and ResponseBuilderImpl and do the wrapping here which
is slightly cleaner, I would set the runtime delegate at startup and should
be good to go (I think). Looks somewhat better, but ResponseBuilderImpl
being final, I would need to probably use it as a delegate inside my impl
and recreate a new response on build() invocations. That seems a bit
extreme though.
-- stephane