We have a bunch of Jiras specific to doing this work - see GEODE-501[23456].
--Jens On Wed, Oct 24, 2018 at 1:01 PM George Wilder <[email protected]> wrote: > Using a JSONArray does fix this specific use case. Thanks for the > pointer. I’ll need to review all our use cases that involve “Objects” to > see if that is a viable change for us. > > > > I’ll also take a peek at the specific Geode use cases. If there is a > fairly small number of usage patterns that could be converted, I’ll see > about opening a jira, unless there’s already one out there. > > > > From what I can see, the only current use of “org.json” classes in Geode > are in the internal cli, the REST API, and a number of tests. Seems like > an app that didn’t use the cli or the REST API at runtime wouldn’t need > geode-json.jar at all. > > > > -- > > George. > > > > *From:* Anthony Baker <[email protected]> > *Sent:* Wednesday, October 24, 2018 3:25 PM > *To:* [email protected] > *Subject:* Re: geode-json.jar : can it be replaced? > > > > *EXTERNAL* > > The code from the original org.json project has a license that is not > OSS-friendly [1]. Our code is based on a clean room implementation from > [2]. Personally I would like to git rid of this module entirely and just > use Jackson for json parsing within Geode. > > > > Have you tried something like this: > > > > matchPars.put(“terms”, new JSONArray(terms)); > > > > > > Anthony > > > > [1] https://www.apache.org/legal/resolved.html > > [2] https://github.com/tdunning/open-json > > > > > > On Oct 24, 2018, at 9:04 AM, George Wilder <[email protected]> wrote: > > > > Hi Jens: > > > > The code is calling org.json.JSONObject.put(String key, Set<String> > value). When using geode-json.jar, the resulting JSONObject is a > JSONString. Here’s is a simple example: > > > > * import* java.util.HashSet; > > * import* java.util.Set; > > * import* java.util.stream.Collectors; > > * import* java.util.stream.Stream; > > * import* org.json.JSONObject; > > * import* com.fasterxml.jackson.core.type.TypeReference; > > * import* com.fasterxml.jackson.databind.ObjectMapper; > > > > *public* *static* *void* main(String[] args) { > > JSONObject matchPars = *new* JSONObject(); > > Set<String> terms = Stream.*of*("one", "two", "three","four" > ).collect(Collectors.*toCollection*(HashSet::*new*)); > > matchPars.put("terms", terms); > > System.*out*.println(matchPars.toString()); > > > > //At this point, assume the JSON Object is being sent over the > wire to some other non-java application > > //which may have its own JSON parser. I'll simulate that by > making use of *Jackson*. > > > > *try* { > > ObjectMapper jsonMapper = *new* ObjectMapper(); > > Set<String> marshalledSet = *new* HashSet<>(); > > > > Object jsonSet = matchPars.get("terms"); > > marshalledSet = jsonMapper.readValue( jsonSet.toString(), > *new*TypeReference<Set<String>>(){} ); > > System.*out*.println("Marshalled Set = " + marshalledSet); > > } *catch* (Exception e) { > > e.printStackTrace(); > > } > > } > > > > When using the geode-json.jar implementation, the result of the above code > is a mapping exception in the second part, as the code expects a > Set<String>, but gets a String. > > When using an alternative implementation, > https://mvnrepository.com/artifact/org.json/json/20180813, for example, > the code runs clean since the JSONObject is an actual JSONObject containing > a set of Strings. > > > > I believe I have a couple of options: > > > > - Replace geode-json.jar and hope basic Region functionality does not > break, and/or > > - Remove all use of org.json.* from the application, replacing it with > some non org.json packaged parser. > > > > I’m leading towards doing both – short term fix of replacing the > dependency on geode-json (just remove the jar from runtime deployments), > long term remove references to org.json.*. > > > > Has there been any thought of re-packaging the Geode custom JSON > implementation, perhaps something like org.apache.geode.json.* ? > > > > -- > > George > > > > *From:* Jens Deppe <[email protected]> > *Sent:* Wednesday, October 24, 2018 10:23 AM > *To:* [email protected] > *Subject:* Re: geode-json.jar : can it be replaced? > > > > *EXTERNAL* > > Hi George, > > > > Unfortunately you cannot replace the geode-json jar with an alternative > implementation - the reason it is there is partly because of customized > changes. > > > > You say: "When using the geode-json.jar, the conversion from Set to JSON > results in a String..." - how exactly are you doing this conversion? Is > there an API you're calling explicitly? > > > > --Jens > > > > On Wed, Oct 24, 2018 at 7:04 AM George Wilder <[email protected]> > wrote: > > What are possible negative effects of replacing geode-json.jar with a > different implementation of the org.json package? I’m currently using > version 1.6, but have plans to move to latest available. > > > > I ask because I have a conflict in requirements. My application makes use > of Geode Regions as a distributed data Map, but also needs to be able to > convert a Set<String> to JSON and back. When using the geode-json.jar, the > conversion from Set to JSON results in a String : “[one, two, three]”, but > converting that “String” back to a Set requires modification of the > String. When I use alternate JSON implementations, the conversion from Set > to JSON results in a Collection of String : [“one”, “two”, “three”], which > converts back to a Set directly > > > > I do not have any plans to store native JSON documents in Geode Regions. > I build my applications as a Spring-Boot fat jar and consume the > geode-json.jar as a transitive dependency from geode-core.jar. > > > > Thanks, > > George. > > >
