You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geode.apache.org by George Wilder <Ge...@sas.com> on 2018/10/24 14:04:47 UTC
geode-json.jar : can it be replaced?
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.
Re: geode-json.jar : can it be replaced?
Posted by Jens Deppe <jd...@pivotal.io>.
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 <Ge...@sas.com> 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 <ab...@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 <Ge...@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(),
> *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 <jd...@pivotal.io>
> *Sent:* Wednesday, October 24, 2018 10:23 AM
> *To:* 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 <Ge...@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.
>
>
>
RE: geode-json.jar : can it be replaced?
Posted by George Wilder <Ge...@sas.com>.
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 <ab...@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 <Ge...@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 <jd...@pivotal.io>>
Sent: Wednesday, October 24, 2018 10:23 AM
To: user@geode.apache.org<ma...@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 <Ge...@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.
Re: geode-json.jar : can it be replaced?
Posted by Anthony Baker <ab...@pivotal.io>.
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 <Ge...@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 <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 <jdeppe@pivotal.io <ma...@pivotal.io>>
> Sent: Wednesday, October 24, 2018 10:23 AM
> To: user@geode.apache.org <ma...@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.Wilder@sas.com <ma...@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.
RE: geode-json.jar : can it be replaced?
Posted by George Wilder <Ge...@sas.com>.
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 <jd...@pivotal.io>
Sent: Wednesday, October 24, 2018 10:23 AM
To: 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 <Ge...@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.
Re: geode-json.jar : can it be replaced?
Posted by Jens Deppe <jd...@pivotal.io>.
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 <Ge...@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.
>