A few quick questions/comments. What is the plan for the binary distribution going to look like? I see there's already a JIRA for adding wink-providers to the distribution (I'm assuming the code in Wink compiled in JARs). Is the plan then also to include the json.org JAR and other JSON implementation JARs for the other providers in the binary distribution?
>From a user perspective, I think JSON support will be a common scenario. I didn't think it was an issue previously because of the built-in JSON support already provided but if out-of-the-box, there isn't a JSON provider, then I think it is inconvenient for users to have to find the necessary and correct versions of JARs. For instance, I can just imagine some user thinking that they can just drop the wink-json-provider and expecting it to magically work. Just my opinion. I like the autoregistration improvement idea of providers. On Tue, Sep 15, 2009 at 3:51 AM, Baram, Eliezer <[email protected]> wrote: > 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? > -- - Bryant Luk
