RE: geode-json.jar : can it be replaced?

[George Wilder]

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 <aba...@pivotal.io>
Sent: Wednesday, October 24, 2018 3:25 PM
To: user@geode.apache.org
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 
<george.wil...@sas.com<mailto:george.wil...@sas.com>> 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(), 
newTypeReference<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 <jde...@pivotal.io<mailto:jde...@pivotal.io>>
Sent: Wednesday, October 24, 2018 10:23 AM
To: user@geode.apache.org<mailto:user@geode.apache.org>
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 
<george.wil...@sas.com<mailto:george.wil...@sas.com>> 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.