On Jan 14, 2010, at 3:16 PM, Comerford, Sean wrote:
> So I’m slowly working through a prototype application and have a
> couple of high level newbie questions.
>
> Q1) How to best provide a “light” XML/JSON feed?
>
> Initial testing has shown that (due to performance considerations) I
> need to slim down the markup I’m outputting. Un/marshalling costs
> are just too high if I output all the fields we have in our POJOs.
>
> I can easily accomplish that by marking a lot of stuff @XmlTransient
> so it’s omitted.
>
> But the problem with that is there are SOME cases where I really do
> need want those fields in the markup.
>
> So what I’m looking to do is develop a “light” and “full” version of
> my output. Short of basic coding conventions (i.e. gving multiple
> classes representing the same underlying data but with differing
> JAXB annotations), does jersey or JAXB provide anything in this
> respect?
>
No, currently the application developer has to do that when using JAXB.
> Creating resource “views” is one possible solution I guess but I’m
> not sure that feels right and it certainly loses some of the
> “automagic” benefit of the Jersey+JAXB framework but perhaps I’m
> missing something.
>
> Q2) Controlling the Jersey life cycle... I could have sworn I saw an
> example of this but can’t seem to find now. Let’s say for the sake
> of argument I want to marshal my Java objects to XML myself (maybe
> to cache the JAXB generated markup) and have my @GET method return
> that instead of a JAXB annotated POJO instance.... How do I do
> that / can someone point me to an example?
>
You could make the resource class a singleton and cache in a field of
byte[] of the serialization on the first request.
@Singleton
public class MyResource {
byte[] xyz;
@GET
public byte[] get() {
synchronized(this) {
if (xyz == null) {
// cache
}
return xyz;
}
}
}
I think there may be more general solutions using etags and ehcache or
using a web proxy with appropriate cache-control headers.
Paul.