One side topic to this too is how to name the packages. I made the changes for WINK-180 ( https://issues.apache.org/jira/browse/WINK-180 ). However if we're expecting users to never call "internal" code, I think we should move the providers out of internal packages. I think it causes confusion on what is internal or not. If I were a user that called into internal code and am risk adverse, I wouldn't use the provider.
Thoughts? On Tue, Sep 15, 2009 at 9:55 AM, Bryant Luk <[email protected]> wrote: > 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 > -- - Bryant Luk
