Hi Agree, we should move the JSON provider to a new module under wink-providers. It helps in reducing the dependency of third party, and makes it easier to the user to understand which provider is used, especially now when we have more then one JSON provider. It better we implement the change before the release of 1.0, to avoid backward compatibility breaks in minor version.
--Eli -----Original Message----- From: Michael Elman [mailto:[email protected]] Sent: Sunday, September 13, 2009 11:54 AM To: [email protected] 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?
