On Mon, Aug 6, 2012 at 3:39 AM, James Green <james.mk.green_at_gmail.com> wrote:
> Tatu,
>
> We chose the Java EE platform for our next set of development work after
> reading "Beginning Java EE 6 Platform with Glassfish 3" and seeing how
> annotations could really drive down LoC and consequently costs of
> development.
I agree, annotations are great.
> Once I found both JBoss and Glassfish supported JSON out of the box I tested
> and found my models differed quite a lot. Given no choice of AS server has
> been made, documenting API requests and responses for JSON representations
> is impossible.
Yes, this is mostly due to historical reasons, and very much misguided
attempts (IMO) to shoehorn JSON support via existing XML support. This
produces "franken-JSON", adds complexity, and is all around Bad Idea.
Which is why I suggest you would skip those legacy approaches and go
with clean(er) JSON to/from POJOs data binding.
> The Jersey documentation for JSON does state that the default mapping is
> likely to be insufficient and that natural is superior in a number of ways.
Right, compared to default mapping, as it was developer to overcome
specific issues.
But unless I am mixing up things, natural mapping is still not quite
as convenient or intuitive as what Jersey calls "POJO mapping".
> My big problem is not being able to specify which notation an application
> server should use, something I think is a big hole.
>
> The custom JABContext for JSON is working for fails to deploy to JBoss. It's
> not right, but until I need JBoss again, that problem will have to wait.
Yes, the situation with configurations is pretty nasty, and I can see
why you would like to see a standardized approach. Unfortunately, as
far as I know, existing JSON JSR does not address either data-binding
or JSON use for higher-level APIs like JAX-RS.
But maybe newer versions of JAX-RS spec can help here? (I have not
kept up to date with specs to be honest)
What I can say however is this: Jackson-based (or, GSON-based, for
that matter) data-binding, using basic MessageBodyReader/-Writer
abstraction, works very well on all JAX-RS containers.
This is because there is little containers have to do: they create
ObjectMapper (or accept one application provides, using standard
Provider interface), and calls its 'readValue()' and 'writeValue()'
methods, and that does conversions. It also means that integration
code tends to be very similar.
So that's the route to take, I think, instead of trying to use
container-specific configuration options, with various settings.
Others can give their opinions -- this is mine.
-+ Tatu +-