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.
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.
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.
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.
James
On 3 August 2012 18:41, Tatu Saloranta <tsaloranta_at_gmail.com> wrote:
> On Thu, Aug 2, 2012 at 11:45 PM, James Green <james.mk.green_at_gmail.com>wrote:
>
>> John,
>>
>> I wrapped up the contents of the constructor in a try/catch to
>> specifically log what was happening but nothing was logged.
>>
>> In the end I commented out all the classes for binding and the
>> constructor was finally invoked.
>>
>> Then I was forced to uncomment the classes until I found the constructor
>> no longer called. As you can imagine, I was swearing at the screen by this
>> time.
>>
>> Anyway I now have the classes loaded having removed a
>> few unnecessary ones and fixed a few others.
>>
>> My next job will be to make this work beyond Arquillian testing, into a
>> real deployment to Glassfish, and to JBoss.
>>
>> Now, before I sign off I want to return the root of the problem: the lack
>> of a cross-container default JSON notation. If it was not for this lack of
>> standardisation I would not be wasting my time this week. My boss doesn't
>> get why I'm having to put this time at all, after-all "Java must do JSON by
>> now". So, I've heard there's a "future spec" to address this point, what
>> news is there of it? I am specifically wanting to ensure that my code today
>> does not rot into the future.
>>
>>
>
> Your simplest fix would probably just to enable use POJO mapping. I am not
> quite sure why you are starting with "natural" notation; maybe some old
> tutorials refer to it?
> POJO mapping is the usual "just works" method, based on Jackson's data
> binding functionality.
>
> The on-going Java JSR will not address data-binding between POJOs and JSON
> at all, so it is mostly irrelevant here, and you don't need to worry about
> that. Not to mention that even when it is finalized, JAX-RS spec would have
> to support it, then implementations (Jersey) etc, so any effect it may have
> will take quite a while.
>
> -+ Tatu +-
>
>