> I would just suggest that we be very clear about how simple it is to pull in and use a "third-party" JSON provider. Suppose we implement autoregistration of providers ( https://issues.apache.org/jira/browse/WINK-181) Pulling the provider will require additional dependency in maven build: <dependency> <groupId>org.apache.wink</groupId> <artifactId>wink-json-provider</artifactId> </dependency>
>What is the plan for the binary distribution going to look like? I think we have already discussed it: http://n2.nabble.com/Proposal-wink-providers-module-td3492779.html#a3492779 Eli described it: http://n2.nabble.com/Proposal-wink-providers-module-tp3492779p3502065.html > can just imagine some user thinking that they can just drop the wink-json-provider and expecting it to magically work. After WINK-181 is implemented, I expect it to happen for maven builds. >I think we should move the providers out of internal packages. Agreed for wink-providers. Especially if provider classes follow MessageBodyReader/Writer APIs and don't expose any public/protected methods. For common/server we can keep the providers in internal, since we register them automatically anyway. On Wed, Sep 16, 2009 at 12:04 AM, Bryant Luk <[email protected]> wrote: > 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 >
