After having worked on using the Jackson provider, and having done a prior
Jettison provider, I'll toss in my agreement too. :) I would just suggest
that we be very clear about how simple it is to pull in and use a
"third-party" JSON provider. I've seen some threads that seem to suggest
that having a built-in JSON provider is a selling point for other JAX-RS
runtimes. (Source:
Side question... perhaps for a different thread... have we considered what
we might do to address the first "con" in your list? How do we intend to
support JSON-to-JAXB? At first glance, one might think the built-in
Jackson JAX-RS provider would support JAXB, but its
JaxbAnnotationIntrospector is actually quite limited.
Just curious, for now.
Thanks.
mike
From: Nicholas Gallardo <[email protected]>
To: [email protected]
Date: 09/14/2009 08:30 AM
Subject: Re: [DISCUSS]: JSON implementations
I'll comment in greater detail later today... but in short I've been
somewhat uncomfortable with this as well.
In the end, I think it's best if we make clear what things we've tested
with and what runtimes we'll accommodate, but allow users to choose what
JSON provider they want. You mentioned it being like SLF4J. Another
analogy I've heard that is appropriate is that it's like a JDBC provider.
I also agree that because of the different generation patterns that are
supported across the various providers, it becomes difficult to understand
which provider to use in which instance. Intersect that with the
particular object type that a user may want to use and it becomes much more
painful than it should be.
Anyway... wanted to get that on the table. More to come. Thanks for
starting the thread Michael.
-Nick
----- Original Message ----
From: Michael Elman <[email protected]>
To: [email protected]
Sent: Sunday, September 13, 2009 3:54:16 AM
Subject: [DISCUSS]: JSON implementations
Hi all,
I'd like to discuss the JSON implementation we have and how they are
organized.
First, we have json.org implementation embedded inside wink-common.
Pros:
- Wink ships with a default JSON implementation.
- The JAXB-to-JSON implementation is quite fast.
Cons:
- Currently there is no JSON-to-JAXB implementation.
- The built-in json-to-xml doesn't use Badgerfish, while our inner
implementation uses Badgerfish. It's inconsistency, since people that
are
familiar with json.org may expect a different behavior.
- wink-common always brings json third-party, even if it is not used.
- There is a license problem with json.org classes (see
https://issues.apache.org/jira/browse/WINK-159)
In addition, we have Jettison support in wink-providers module and Jackson
has built-in JAX-RS providers.
I don't feel comfortable with this approach. Especially with
json.orgsupport we have now.
I prefer to separate it to a an additional module under wink-providers and
use it for both serialization/de-serialization. So anyone may decide which
JSON support to use. Quite similar to Slf4j approach of logging.
However, it changes a behavior with 0.1 and probably not so efficient,
since
a double parsing occurs.
Thoughts?
