> Can't comment on bug part, but I am not sure I follow the argument for use case.
> While JSON has less impedance to/from java objects, wouldn't the
> simplest way be to build actual java objects and just serialize those
> to whichever you actually need? (i.e. just return POJO, not json.org
> ref implementations tree object)
> Or are you trying to work around artifacts caused by mapped
> conventions that are incurred when going through that route (depending
> on json mapper used)?
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.
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".
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.
> 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
either requires excessive configuration or annotations on the
interface in the approaches I have seen so far.
I'm actually pondering to write my own JSON and XML serialization,
which might be a case of not invented here syndrome. Everything I've
seen so far more or less assumes beans (which I consider an
anti-pattern) or special annotations on classes. At the moment I don't
need the deserialization part, so this is relatively straight forward.
Martin