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]<mailto:[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.

Reply via email to