On Thu, Jun 11, 2009 at 8:33 AM, Martin Probst<mail_at_martin-probst.com> wrote:
>> Can't comment on bug part, but I am not sure I follow the argument for use case.
...
> I'm not quite decided on that yet. The issue is that I'm working with
> an API that only consists of opaque interfaces, which I cannot and
> don't want to change. So XMLBeans style is ruled out entirely.
Right. Ideally (I think), JAX-RS rest services defer format
serialization to the end, and having to use format-dependant objects
is not optimal.
Annotations are ok -- they do add bit of coupling, but that's at level
of metadata on business objects, can still be POJOs.
> Now as far as I can see I have the option to directly generate JSON
> Objects as I do now, and convert them to XML somehow. The main problem
> with that is that you don't want a root property name for JSON, but
> you do want one for XML. E.g. { "foo": 15, "bar": "Hello" } should
> translate to <name><foo>15</foo><bar>Hello</bar></name>, but JSON
> Objects don't have a "name".
Yes, that is big part of impedance between json/xml conceptual and
physical models.
And that's why I try to avoid any xml<->json conversions if at all
possible; it just adds one more place to get things mangled.
> Creating special POJO classes for each data structure I want to return
> would work, but seems a bit wasteful. You create lots (or at least
> several...) of "data holder" classes that mirror the public
> information available in the interfaces. It seems more straightforward
> to just build the JSON Objects directly, but again there is the
> mapping issue with the root XML name.
But why not use POJOs themselves? Or can you not add annotations
if/when needed? Maybe you start with non-object data?
>> If latter, JacksonJsonProvider can do 'natural' mapping from Beans (or
>> Map/List/Wrapper structure); similar to how JAXB works (within limits
>> set by xml/object mapping impedance).
>
> Does Jackson use the fields exposed through getters by an interface to
> serialize, or will it use the actual fields of the implementation
> behind that? The latter won't work for me, I think, and the former
As of 1.0 and earlier, only properties implied by setter/getter
methods: implication by Bean-style naming, or explicitly annotated. No
need for any annotations for common beans (no @XmlRootElement, since
no such name is needed for json unlike xml).
1.1 will add similar support for fields (public or annotated); methods
having precedence if both are present for a logical property.
> either requires excessive configuration or annotations on the
> interface in the approaches I have seen so far.
It shouldn't, if classes you use are beans. But then you would need to
have distinct beans to introspect. Jackson does have its own
alternative tree structure (JsonNode) for some use cases, but that's
not very different from json.org's JSONObject et al. Can of course be
smoothly read/written by Jackson, for cases where DOM-style works
best.
And then there is the "untyped Java objects", which is a slight
improvement (IMO) from dom-like trees: just create Java Maps, Lists
and such, and get them serialized. That works as expected with
Jackson: just return Map<?,?>, and it comes out as expected (and can
be read easily too). It may be slightly more difficult with xml, but
JAXB has workarounds for that.
Going back to basics: do you start by just explicitly building the
response? And if so, what is the source data? Often it comes as
objects anyway, which are usually beans. Other times not, like query
results from a DB, but in many of those cases they are regular enough
that you can easily have container (bean/collection/map) class.
I probably do not fully understand context of your usage here... but
working on that part. :)
-+ Tatu +-