You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Clebert Suconic <cl...@gmail.com> on 2016/06/14 21:21:26 UTC
Artemis: Use software for "no Evil"
Accordingly to apache legal, we can use JSON on our codebase, however
other projects may be unable to redistribute your code if you use this
license because of the:
"The Software shall be used for Good, not Evil."
(http://www.apache.org/legal/resolved.html#json)
So, Fedora guys are asking us to replace this on Artemis.
(https://issues.apache.org/jira/browse/ARTEMIS-565)
I looked at HBase and they have been through the same path apparently,
where they replaced it by
https://code.google.com/archive/p/json-simple/
More fun reading at: https://issues.apache.org/jira/browse/ARTEMIS-565
Any volunteer to make the change? :)
--
Clebert Suconic
Re: Artemis: Use software for "no Evil"
Posted by "John D. Ament" <jo...@gmail.com>.
Hey so I meant to follow up on this, but then meh got some time today to
look into this harder.
I raised a PR with a port of the code to use javax.json, no plugged in
provider yet (so tests won't run and I'm sure theres still checkstyle
issues).
https://github.com/apache/activemq-artemis/pull/640
Some things to point out:
- I haven't the slightest idea what json-p provider wildfly uses.
- The geronimo spec jar points to Johnzon as a hard dependency
- Using javax.json would even allow jackson to be dropped in via
https://github.com/FasterXML/jackson-datatype-jsr353
- Artemis may now be used for evil (muwahahahaha)
If the code changes going in here roughly make sense and are agreeable (the
main difference I see is that you can't do new JsonArray(String) any
longer, so I created a util method for that) I'll work on tidying up the
implementation a bit. Wherever possible, I made objects responsible for
creating JSON representations. Unfortunately it is a large change due to
how frequent json is used in the code base.
Some things to still consider:
- What should be the default impl? Is Johnzon OK? Want to bring in Jackson
instead?
- There's a couple of methods I took out that were tested but not used
anywhere else. I want to make sure that no consumers were using these
methods (they looked odd, and were parsing not valid JSON) (see also
ManagementHelper.java).
John
On Wed, Jun 15, 2016 at 12:25 PM Clebert Suconic <cl...@gmail.com>
wrote:
> I looked at what would need to be done if we were going the
> google-simple JSON approach.
>
>
> The API is fairly simpler, it has no support for getString methods,
> instead everything is a get() and you need to use casting to the
> object.
>
> Example:
>
>
> String value = (String)jsonObject.get("value");
>
>
> Instead of
>
>
> String value = jsonObject.getString("value");
>
>
> Besides this we will need to add the new jar to the distribution and
> OSGI. It's a fairly simple change.. just needs to make a few api
> changes and stuff like that.. it's not that bad.
>
>
> @John: did you have experience with this other package you mentioned?
>
>
>
>
>
>
> Clebert
>
>
> PS: Any time I say *we* on my emails, I mean as in Apache ActiveMQ..
> meaning We as in the developers. If i was talking about the company I
> work for or any third party i would write it in the third person.
>
>
> On Tue, Jun 14, 2016 at 6:41 PM, Clebert Suconic
> <cl...@gmail.com> wrote:
> > I was just reading about it.
> >
> > The only requirement I see is not to break the API contract on
> management.
> >
> > Most of the JSON we have is for management responses, where we return
> > objects as JSON Arrays or JSON Objects.
> >
> > Apparently using JSONP would change the responses we have on management?
> >
> > Changing this to JSON-P would apparently mean we have to add a
> > function name to the return?
> >
> > i.e... say... getConnectionsAsJSON currently returns this on the MBean
> Console:
> >
> >
> [{"creationTime":1465943892043,"connectionID":"-1350038013","clientAddress":"/
> 127.0.0.1:64627
> "},{"creationTime":1465943895399,"connectionID":"1668184153","clientAddress":"/
> 127.0.0.1:64628"}]
> >
> >
> >
> > apparently it would start to return something with a function name:
> > that is: getConnectionsAsJSON([......])
> >
> >
> > Which would be an incompatible change for a point release.
> >
> >
> > If we can use the library you mentioned but keeping the same output
> > through management without breaking a contract like this, it would be
> > fine.
> >
> >
> > How do you see it?
> >
> > On Tue, Jun 14, 2016 at 5:30 PM, John D. Ament <jo...@apache.org>
> wrote:
> >> Clebert,
> >>
> >> Would you be interested in an impl based on the JSON-P spec? If so
> maybe
> >> Johnzon would be a solution here.
> >>
> >> John
> >>
> >> On Tue, Jun 14, 2016 at 5:21 PM Clebert Suconic <
> clebert.suconic@gmail.com>
> >> wrote:
> >>
> >>> Accordingly to apache legal, we can use JSON on our codebase, however
> >>> other projects may be unable to redistribute your code if you use this
> >>> license because of the:
> >>>
> >>> "The Software shall be used for Good, not Evil."
> >>>
> >>> (http://www.apache.org/legal/resolved.html#json)
> >>>
> >>>
> >>> So, Fedora guys are asking us to replace this on Artemis.
> >>> (https://issues.apache.org/jira/browse/ARTEMIS-565)
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> I looked at HBase and they have been through the same path apparently,
> >>> where they replaced it by
> >>> https://code.google.com/archive/p/json-simple/
> >>>
> >>>
> >>>
> >>>
> >>> More fun reading at: https://issues.apache.org/jira/browse/ARTEMIS-565
> >>>
> >>>
> >>>
> >>> Any volunteer to make the change? :)
> >>>
> >>>
> >>>
> >>> --
> >>> Clebert Suconic
> >>>
> >
> >
> >
> > --
> > Clebert Suconic
>
>
>
> --
> Clebert Suconic
>
Re: Artemis: Use software for "no Evil"
Posted by Clebert Suconic <cl...@gmail.com>.
I looked at what would need to be done if we were going the
google-simple JSON approach.
The API is fairly simpler, it has no support for getString methods,
instead everything is a get() and you need to use casting to the
object.
Example:
String value = (String)jsonObject.get("value");
Instead of
String value = jsonObject.getString("value");
Besides this we will need to add the new jar to the distribution and
OSGI. It's a fairly simple change.. just needs to make a few api
changes and stuff like that.. it's not that bad.
@John: did you have experience with this other package you mentioned?
Clebert
PS: Any time I say *we* on my emails, I mean as in Apache ActiveMQ..
meaning We as in the developers. If i was talking about the company I
work for or any third party i would write it in the third person.
On Tue, Jun 14, 2016 at 6:41 PM, Clebert Suconic
<cl...@gmail.com> wrote:
> I was just reading about it.
>
> The only requirement I see is not to break the API contract on management.
>
> Most of the JSON we have is for management responses, where we return
> objects as JSON Arrays or JSON Objects.
>
> Apparently using JSONP would change the responses we have on management?
>
> Changing this to JSON-P would apparently mean we have to add a
> function name to the return?
>
> i.e... say... getConnectionsAsJSON currently returns this on the MBean Console:
>
> [{"creationTime":1465943892043,"connectionID":"-1350038013","clientAddress":"/127.0.0.1:64627"},{"creationTime":1465943895399,"connectionID":"1668184153","clientAddress":"/127.0.0.1:64628"}]
>
>
>
> apparently it would start to return something with a function name:
> that is: getConnectionsAsJSON([......])
>
>
> Which would be an incompatible change for a point release.
>
>
> If we can use the library you mentioned but keeping the same output
> through management without breaking a contract like this, it would be
> fine.
>
>
> How do you see it?
>
> On Tue, Jun 14, 2016 at 5:30 PM, John D. Ament <jo...@apache.org> wrote:
>> Clebert,
>>
>> Would you be interested in an impl based on the JSON-P spec? If so maybe
>> Johnzon would be a solution here.
>>
>> John
>>
>> On Tue, Jun 14, 2016 at 5:21 PM Clebert Suconic <cl...@gmail.com>
>> wrote:
>>
>>> Accordingly to apache legal, we can use JSON on our codebase, however
>>> other projects may be unable to redistribute your code if you use this
>>> license because of the:
>>>
>>> "The Software shall be used for Good, not Evil."
>>>
>>> (http://www.apache.org/legal/resolved.html#json)
>>>
>>>
>>> So, Fedora guys are asking us to replace this on Artemis.
>>> (https://issues.apache.org/jira/browse/ARTEMIS-565)
>>>
>>>
>>>
>>>
>>>
>>> I looked at HBase and they have been through the same path apparently,
>>> where they replaced it by
>>> https://code.google.com/archive/p/json-simple/
>>>
>>>
>>>
>>>
>>> More fun reading at: https://issues.apache.org/jira/browse/ARTEMIS-565
>>>
>>>
>>>
>>> Any volunteer to make the change? :)
>>>
>>>
>>>
>>> --
>>> Clebert Suconic
>>>
>
>
>
> --
> Clebert Suconic
--
Clebert Suconic
Re: Artemis: Use software for "no Evil"
Posted by Clebert Suconic <cl...@gmail.com>.
I was just reading about it.
The only requirement I see is not to break the API contract on management.
Most of the JSON we have is for management responses, where we return
objects as JSON Arrays or JSON Objects.
Apparently using JSONP would change the responses we have on management?
Changing this to JSON-P would apparently mean we have to add a
function name to the return?
i.e... say... getConnectionsAsJSON currently returns this on the MBean Console:
[{"creationTime":1465943892043,"connectionID":"-1350038013","clientAddress":"/127.0.0.1:64627"},{"creationTime":1465943895399,"connectionID":"1668184153","clientAddress":"/127.0.0.1:64628"}]
apparently it would start to return something with a function name:
that is: getConnectionsAsJSON([......])
Which would be an incompatible change for a point release.
If we can use the library you mentioned but keeping the same output
through management without breaking a contract like this, it would be
fine.
How do you see it?
On Tue, Jun 14, 2016 at 5:30 PM, John D. Ament <jo...@apache.org> wrote:
> Clebert,
>
> Would you be interested in an impl based on the JSON-P spec? If so maybe
> Johnzon would be a solution here.
>
> John
>
> On Tue, Jun 14, 2016 at 5:21 PM Clebert Suconic <cl...@gmail.com>
> wrote:
>
>> Accordingly to apache legal, we can use JSON on our codebase, however
>> other projects may be unable to redistribute your code if you use this
>> license because of the:
>>
>> "The Software shall be used for Good, not Evil."
>>
>> (http://www.apache.org/legal/resolved.html#json)
>>
>>
>> So, Fedora guys are asking us to replace this on Artemis.
>> (https://issues.apache.org/jira/browse/ARTEMIS-565)
>>
>>
>>
>>
>>
>> I looked at HBase and they have been through the same path apparently,
>> where they replaced it by
>> https://code.google.com/archive/p/json-simple/
>>
>>
>>
>>
>> More fun reading at: https://issues.apache.org/jira/browse/ARTEMIS-565
>>
>>
>>
>> Any volunteer to make the change? :)
>>
>>
>>
>> --
>> Clebert Suconic
>>
--
Clebert Suconic
Re: Artemis: Use software for "no Evil"
Posted by "John D. Ament" <jo...@apache.org>.
Clebert,
Would you be interested in an impl based on the JSON-P spec? If so maybe
Johnzon would be a solution here.
John
On Tue, Jun 14, 2016 at 5:21 PM Clebert Suconic <cl...@gmail.com>
wrote:
> Accordingly to apache legal, we can use JSON on our codebase, however
> other projects may be unable to redistribute your code if you use this
> license because of the:
>
> "The Software shall be used for Good, not Evil."
>
> (http://www.apache.org/legal/resolved.html#json)
>
>
> So, Fedora guys are asking us to replace this on Artemis.
> (https://issues.apache.org/jira/browse/ARTEMIS-565)
>
>
>
>
>
> I looked at HBase and they have been through the same path apparently,
> where they replaced it by
> https://code.google.com/archive/p/json-simple/
>
>
>
>
> More fun reading at: https://issues.apache.org/jira/browse/ARTEMIS-565
>
>
>
> Any volunteer to make the change? :)
>
>
>
> --
> Clebert Suconic
>