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.