Tatu,
Thanks very much for your thoughts. I'm not adverse to your suggestion.
Looking at the documentation and at the zip file sample, I'm still
struggling to see how this can be made portable. Is there some magic I am
missing/misunderstanding that developers use to customise their
applications when deployed to certain containers or something?
If I were to port the sample linked from the Jersey docs into application
and deploy to JBoss surely it'll complain about the jersey dependencies?
Thanks for your continuing comments.
James
On 7 August 2012 00:21, Tatu Saloranta <tsaloranta_at_gmail.com> wrote:
> 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 +-
>