Hi Stephane, please see inline...
On 2.8.2011 2:08, Stephane Bailliez wrote:
> On Mon, Aug 1, 2011 at 10:12 AM, Jakub Podlesak
> <jakub.podlesak_at_oracle.com <mailto:jakub.podlesak_at_oracle.com>> wrote:
>
> Hi,
>
> You might be able to utilize the ResourceFilter API (see [1]).
> That also gives you an opportunity to select, which resource
> output would be decorated.
>
>
> mmm indeed. I was initially discarding this option it since I found it
> would be a bit too cumbersome to specify it constantly but looks like
> it could be the best approach. I tried the one I mentioned, and
> quickly bumped into the issue that it would be decorating absolutely
> everything, which in practice is not really the case. I would need to
> be able to know the media type before the response is created and
> likely do some other gymnastics.
You can still change the response/create a new one with the
ResponseFilter (see [3]).
The original media type is accessible via the response parameter (see [4]).
On the other hand this is maybe too high level approach, as you write
above about media type related
processing. Then the MessageBodyWorker proxy approach should IMHO suit
you better.
>
> There is also the option of case by case basis (typically would want
> to do the same in an exception mapper when I generate a standard error
> response with the same structure), in this case I think it makes more
> sense to do it manually.
You can also inject and use the MessageBodyWorkers in the exception
mappers. The same pattern could apply there.
>
>
> Another option is to "override" the default MessageBodyWriter [2]
> providers
> by implementing a custom proxy provider, which could do the
> decoration for you.
> The default providers could get injected to this proxy with
> Providers [3] iface
> so that data serialization could be delegated to them as needed.
>
>
> mmm.. I think I would end up with the same problem as my initial run
> here...(me think)
For both options, you can decide what to decorate case by case, no need
to blindly wrap everything.
~Jakub
[3]
http://jersey.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/spi/container/ContainerResponseFilter.html
[4]
http://jersey.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/spi/container/ContainerResponse.html
>
> Thanks
>
>
>
>
> HTH,
>
> ~Jakub
>
> [1]http://jersey.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/spi/container/ResourceFilterFactory.html
> [2]http://jersey.java.net/nonav/apidocs/latest/jersey/javax/ws/rs/ext/MessageBodyWriter.html
> [3]http://jersey.java.net/nonav/apidocs/latest/jersey/javax/ws/rs/ext/Providers.html
>
>
>
> On 30.7.2011 22:32, sbailliez_at_gmail.com
> <mailto:sbailliez_at_gmail.com> wrote:
>
> For all rest services responses, I would like to provide a
> consistent
> response format which includes some headers/metadata/information
> related to the operations. Typically include in the response
> itself,
> the hostname, the operation timing information, etc.. I may pass
> information in http headers as well.
>
> so in json, something like:
> {
> "headers": { "timing": 12, "hostname": "alpha-svc",
> timestamp: "2011-08-01T00:01:02Z", "service": { "version":
> "1.2.3",
> "name": "alpha" }
> ...},
> "data": ...
> }
>
> So the "header" parts would need to be added for all
> responses, whereas
> the data is effectively the response entity.
>
> Is there any particular place that one think of would be
> suitable to
> decorate entity response in such a way ? I was thinking it could
> probably be done by binding the headers metadata information
> to the
> thread local then use a special implementation of the
> messagebodywriter
> to decorate the entity.
>
> Thoughts ?
>
>