On Feb 17, 2009, at 1:08 AM, Tatu Saloranta wrote:
> --- On Mon, 2/16/09, Paul Sandoz <Paul.Sandoz_at_Sun.COM> wrote:
>
> ...
>> Potentially there are some advantages. JAXB has some
>> interesting ways of extending the binding of data types.
>> Character data as well as structure can be validated. It
>> should also be possible to support a general filtering
>> approach in an abstract fashion based on the StAX API (a
>> developer has added a patch to do just that).
>
> True: it's just that fundamentally it is closely bound to xml.
> And I wish there was something that wasn't. There are many aspects
> to data binding that are not strongly bound to the data format.
>
> So I like many things in JAXB per se; but the baggage of xml
> compatiblity (including using stax API which likewise is not a good
> match with json) is the problem.
I would say not a perfect match :-)
My hope is that we may have hit a reasonably 80% mark, but we need
some more data to ascertain that. I want to compare XML to the
"natural" JSON to badger fish JSON for a complex piece of XML, say
using UBL purchase orders.
>
> ...
>>> Conceptually that is the case already; types accepted
>>> and returned are annotated, without need for directly
>>> referencing machinery that does conversions.
>>
>> If i understand you correctly then we may have what you
>> require: JAX-RS message body readers/writers.
>
> That could well be true. :-)
>
> I wish I had more time to play with Jersey, I am sure I am missing
> useful facilities that would make life easier.
>
> ...
>> But may be for the case JAXB-related types it needs some
>> finessing if you want to plug in an alternative JSON-based
>> convention that does not go through the JAXB infrastructure
>> but wants to use the same types i.e. we would like to ensure
>> that JSON plays nice with JAXB or not depending on what
>> convention you choose, in addition to the case when those
>> types are not associated with JAXB annotations but still
>> require support for JSON.
>
> In a way my point is that there should be no need to play nicely
> with JAXB types: JAXB can be used with Objects<->XML conversion, and
> something else for Object<->Json; or, Object<->hessian and so on.
>
Right.
> Perhaps that's to be handled with body handlers?
>
It can, because the media types are different. IIUC Java YAML supports
any Java type for serialization, i am surprised there is not something
for JSON that does something similar.
We may need something a little extra to place nice with multiple JSON
conventions for JAXB objects, when not using the JAXB infrastructure.
>>> At this point this is just wishful thinking; with 1.x
>> release it's not possible to change core API
>> depedencies. But maybe for 2.0? ;-)
>>>
>>
>> :-) would you be interested in helping out?
>
> Sure. I think Jersey (and JAX-RS) has enough promise to make it
> worthwhile to follow, use and maybe help with if I can.
>
OK!
Paul.