users@jersey.java.net

[Jersey] Re: Pluggable StAX message body writers as streaming alternative to JAXB POJO's?

From: Casper Bang <casper.bang_at_gmail.com>
Date: Fri, 25 Mar 2011 07:00:21 +0100

>
> Stax API is for XML; although some libraries like Jettison (ab)use it
> to produce kind of JSON.
> But it is not a general way to produce formats other than XML; I can't
> think of a Java API that does this.
>

I am not sure I see a great difference between (ab)using JAXB annotations to
generate JSON vs. doing it based on StAX events - both caters to a concrete
format of XML and can be seen as a superset to JSON (which has no
namespaces, no atributtes, no collection wrappers etc.).

So in that sense, ability to use streaming is currently a data-format
> specific thing.
>

JAXB is obviously a handy way to assign mapping meta-data to POJO's, OTOH
you effectually pollute your model and makes it impossible to use the same
POJO to emit different projections (i.e. limit depth, elements
or attributes depending on resource context). Both seems related to
the data-format (or rather, data-representation).

I am not sure JAX-RS or Jersey should try to standardize on this,
> given that there is no way to make it really generic.
>

Again, not sure I see a great difference between returning a full POJO tree
with meta-data vs. lazily streaming akin to individual JAXB nodes. The main
 difference just seems to be *when* the message body writers starts to get
something to work with and starts sending a response back to the client. But
perhaps there's something I am missing.

For output it is actually easy to do streaming output, by using
> StreamingOutput wrapper, which gets invoked by Jersey, with
> OutputStream to send output to.
>

Yes it's fairly easy, but to obtain any kind of reuse between multiple
representations (i.e. XML and JSON), one has to invent a custom callback
layer between getting the context to build a response (i.e. iterating over a
resultset) and actually constructing the result (writing nodes via StAX,
XStream, Jettison etc.). It's this step I am seeking to generalize in light
of OData (and other) query language and dynamic results on top of Jersey.



> For input side there isn't equivalent abstraction (due to mapping
> needs), so MessageBodyReader impl is needed.
>

Right, one must assume that a matched resource and headers/parameters passed
to it, is enough context to work with. Such message body readers would
almost by definition need to be event based or could not possibly map to
type-safe Java structures.

Anyway, just throwing some ideas around. Thanks for participating. :)

/Casper