Re: Remove Jackson from ActiveMQ classic
FYI, Romain provided a PR to use Apache Johnson while ago: https://github.com/apache/activemq/pull/308 The PR is fine (I already tested when submitted), it just needs a rebase. If we agree, I can move forward on this one. Regards JB On Wed, May 17, 2023 at 4:04 AM Justin Bertram wrote: > > For what it's worth, Artemis uses JSON-P [1] since it's a standard, simple > API. We use Apache Johnzon for the implementation. It does everything we > need given our relatively basic use-cases. > > Additionally, we wrap the API so that all the broker code can use the > wrapper and the wrapper can be modified to work in Java EE or Jakarta EE > environments. > > > Justin > > [1] > https://javaee.github.io/javaee-spec/javadocs/javax/json/package-summary.html > > On Tue, May 16, 2023 at 6:02 PM Christopher Shannon < > christopher.l.shan...@gmail.com> wrote: > > > Yes, this keeps coming up and as JB said I don't see a problem with > > Jackson, it can be updated for CVEs and works very well and is quite > > feature rich in case we need it. > > > > If we are going to do any JSON serialization I don't want to re-invent the > > wheel and create our own serializer, so we should at least use an existing > > library, even if we make it pluggable like JSON-B. > > > > There's alternatives too like Gson if we wanted something > > smaller/lightweight. > > > > On Tue, May 16, 2023 at 3:11 PM Jean-Baptiste Onofré > > wrote: > > > > > Hi, > > > > > > We discussed this already in the past. IMHO, we can replace jackson by > > > just sax (no need to use JSON-B regarding our usage). > > > > > > That sasid, I don't see any huge issue with Jackson: it works fine and > > > we keep the versions up to date to fix CVE. > > > > > > The only interesting move would be to use SAX parsing directly instead > > > of a mapper. > > > > > > Regards > > > JB > > > > > > On Tue, May 16, 2023 at 12:17 PM Jean-Louis Monteiro > > > wrote: > > > > > > > > Hi all, > > > > > > > > Jackson seems to be frequently affected by CVEs and it's really a pain > > > for > > > > users. > > > > > > > > Looks like Jackson is only used in the WebConsole to read/write a few > > > > attributes. I'm sure we can get rid of it and either use a standard API > > > so > > > > one can plugin any implementation, or just write down a utility class > > to > > > > parse the small attribute we have to. > > > > > > > > thoughts? > > > > > > > > I'm happy to do a PR to remove it if that's the consensus. > > > > > > > > -- > > > > Jean-Louis Monteiro > > > > http://twitter.com/jlouismonteiro > > > > http://www.tomitribe.com > > > > >
Re: Remove Jackson from ActiveMQ classic
For what it's worth, Artemis uses JSON-P [1] since it's a standard, simple API. We use Apache Johnzon for the implementation. It does everything we need given our relatively basic use-cases. Additionally, we wrap the API so that all the broker code can use the wrapper and the wrapper can be modified to work in Java EE or Jakarta EE environments. Justin [1] https://javaee.github.io/javaee-spec/javadocs/javax/json/package-summary.html On Tue, May 16, 2023 at 6:02 PM Christopher Shannon < christopher.l.shan...@gmail.com> wrote: > Yes, this keeps coming up and as JB said I don't see a problem with > Jackson, it can be updated for CVEs and works very well and is quite > feature rich in case we need it. > > If we are going to do any JSON serialization I don't want to re-invent the > wheel and create our own serializer, so we should at least use an existing > library, even if we make it pluggable like JSON-B. > > There's alternatives too like Gson if we wanted something > smaller/lightweight. > > On Tue, May 16, 2023 at 3:11 PM Jean-Baptiste Onofré > wrote: > > > Hi, > > > > We discussed this already in the past. IMHO, we can replace jackson by > > just sax (no need to use JSON-B regarding our usage). > > > > That sasid, I don't see any huge issue with Jackson: it works fine and > > we keep the versions up to date to fix CVE. > > > > The only interesting move would be to use SAX parsing directly instead > > of a mapper. > > > > Regards > > JB > > > > On Tue, May 16, 2023 at 12:17 PM Jean-Louis Monteiro > > wrote: > > > > > > Hi all, > > > > > > Jackson seems to be frequently affected by CVEs and it's really a pain > > for > > > users. > > > > > > Looks like Jackson is only used in the WebConsole to read/write a few > > > attributes. I'm sure we can get rid of it and either use a standard API > > so > > > one can plugin any implementation, or just write down a utility class > to > > > parse the small attribute we have to. > > > > > > thoughts? > > > > > > I'm happy to do a PR to remove it if that's the consensus. > > > > > > -- > > > Jean-Louis Monteiro > > > http://twitter.com/jlouismonteiro > > > http://www.tomitribe.com > > >
Re: Remove Jackson from ActiveMQ classic
Yes, this keeps coming up and as JB said I don't see a problem with Jackson, it can be updated for CVEs and works very well and is quite feature rich in case we need it. If we are going to do any JSON serialization I don't want to re-invent the wheel and create our own serializer, so we should at least use an existing library, even if we make it pluggable like JSON-B. There's alternatives too like Gson if we wanted something smaller/lightweight. On Tue, May 16, 2023 at 3:11 PM Jean-Baptiste Onofré wrote: > Hi, > > We discussed this already in the past. IMHO, we can replace jackson by > just sax (no need to use JSON-B regarding our usage). > > That sasid, I don't see any huge issue with Jackson: it works fine and > we keep the versions up to date to fix CVE. > > The only interesting move would be to use SAX parsing directly instead > of a mapper. > > Regards > JB > > On Tue, May 16, 2023 at 12:17 PM Jean-Louis Monteiro > wrote: > > > > Hi all, > > > > Jackson seems to be frequently affected by CVEs and it's really a pain > for > > users. > > > > Looks like Jackson is only used in the WebConsole to read/write a few > > attributes. I'm sure we can get rid of it and either use a standard API > so > > one can plugin any implementation, or just write down a utility class to > > parse the small attribute we have to. > > > > thoughts? > > > > I'm happy to do a PR to remove it if that's the consensus. > > > > -- > > Jean-Louis Monteiro > > http://twitter.com/jlouismonteiro > > http://www.tomitribe.com >
Re: Remove Jackson from ActiveMQ classic
Hi, We discussed this already in the past. IMHO, we can replace jackson by just sax (no need to use JSON-B regarding our usage). That sasid, I don't see any huge issue with Jackson: it works fine and we keep the versions up to date to fix CVE. The only interesting move would be to use SAX parsing directly instead of a mapper. Regards JB On Tue, May 16, 2023 at 12:17 PM Jean-Louis Monteiro wrote: > > Hi all, > > Jackson seems to be frequently affected by CVEs and it's really a pain for > users. > > Looks like Jackson is only used in the WebConsole to read/write a few > attributes. I'm sure we can get rid of it and either use a standard API so > one can plugin any implementation, or just write down a utility class to > parse the small attribute we have to. > > thoughts? > > I'm happy to do a PR to remove it if that's the consensus. > > -- > Jean-Louis Monteiro > http://twitter.com/jlouismonteiro > http://www.tomitribe.com
Re: Remove Jackson from ActiveMQ classic
I'll take a look Thank you Le mar. 16 mai 2023, 16:18, Matt Pavlovich a écrit : > Yeah, I think we could move to some sort of statically generated JSON text > writer— esp for the PersistenceAdapterView.java. > > A quick scan shows one use of an unmarshaller (which is where most > security problems come from). Perhaps we deprecate that function and > convert the functionality to use a different syntax for the destination > filtering. > > Classes using an import from com.fasterxml.jackson. > > > ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java > > ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Target.java > > ./activemq-console/src/main/java/org/apache/activemq/console/command/store/StoreExporter.java > > ./activemq-broker/src/test/java/org/apache/activemq/broker/view/BrokerDestinationViewTest.java > > ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java > > ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/PersistenceAdapterView.java > > Thanks, > Matt Pavlovich > > > On May 16, 2023, at 8:44 AM, Jean-Louis Monteiro < > jlmonte...@tomitribe.com> wrote: > > > > Yes I remember the discussion. > > To be honest, as I was mentioning, even JSON-B/P is probably overkill for > > what we need. > > > > Happy to craft up a PR so we can it discuss there and see if that is > > feasible for 5.19.x > > -- > > Jean-Louis Monteiro > > http://twitter.com/jlouismonteiro > > http://www.tomitribe.com > > > > > > On Tue, May 16, 2023 at 3:37 PM Matt Pavlovich > wrote: > > > >> Hello Jean-Louis- > >> > >> This has come up in the past. Iirc, the discussion was leaning towards > >> using json-b and then Jackson as the out-of-the-box provider. > >> > >> This sounds like a good change for 5.19.x line > >> > >> Thanks, > >> -Matt Pavlovich > >> > >>> On May 16, 2023, at 5:17 AM, Jean-Louis Monteiro < > >> jlmonte...@tomitribe.com> wrote: > >>> > >>> Hi all, > >>> > >>> Jackson seems to be frequently affected by CVEs and it's really a pain > >> for > >>> users. > >>> > >>> Looks like Jackson is only used in the WebConsole to read/write a few > >>> attributes. I'm sure we can get rid of it and either use a standard API > >> so > >>> one can plugin any implementation, or just write down a utility class > to > >>> parse the small attribute we have to. > >>> > >>> thoughts? > >>> > >>> I'm happy to do a PR to remove it if that's the consensus. > >>> > >>> -- > >>> Jean-Louis Monteiro > >>> http://twitter.com/jlouismonteiro > >>> http://www.tomitribe.com > >> > >> > >
Re: Remove Jackson from ActiveMQ classic
Yeah, I think we could move to some sort of statically generated JSON text writer— esp for the PersistenceAdapterView.java. A quick scan shows one use of an unmarshaller (which is where most security problems come from). Perhaps we deprecate that function and convert the functionality to use a different syntax for the destination filtering. Classes using an import from com.fasterxml.jackson. ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Partitioning.java ./activemq-partition/src/main/java/org/apache/activemq/partition/dto/Target.java ./activemq-console/src/main/java/org/apache/activemq/console/command/store/StoreExporter.java ./activemq-broker/src/test/java/org/apache/activemq/broker/view/BrokerDestinationViewTest.java ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/DestinationsViewFilter.java ./activemq-broker/src/main/java/org/apache/activemq/broker/jmx/PersistenceAdapterView.java Thanks, Matt Pavlovich > On May 16, 2023, at 8:44 AM, Jean-Louis Monteiro > wrote: > > Yes I remember the discussion. > To be honest, as I was mentioning, even JSON-B/P is probably overkill for > what we need. > > Happy to craft up a PR so we can it discuss there and see if that is > feasible for 5.19.x > -- > Jean-Louis Monteiro > http://twitter.com/jlouismonteiro > http://www.tomitribe.com > > > On Tue, May 16, 2023 at 3:37 PM Matt Pavlovich wrote: > >> Hello Jean-Louis- >> >> This has come up in the past. Iirc, the discussion was leaning towards >> using json-b and then Jackson as the out-of-the-box provider. >> >> This sounds like a good change for 5.19.x line >> >> Thanks, >> -Matt Pavlovich >> >>> On May 16, 2023, at 5:17 AM, Jean-Louis Monteiro < >> jlmonte...@tomitribe.com> wrote: >>> >>> Hi all, >>> >>> Jackson seems to be frequently affected by CVEs and it's really a pain >> for >>> users. >>> >>> Looks like Jackson is only used in the WebConsole to read/write a few >>> attributes. I'm sure we can get rid of it and either use a standard API >> so >>> one can plugin any implementation, or just write down a utility class to >>> parse the small attribute we have to. >>> >>> thoughts? >>> >>> I'm happy to do a PR to remove it if that's the consensus. >>> >>> -- >>> Jean-Louis Monteiro >>> http://twitter.com/jlouismonteiro >>> http://www.tomitribe.com >> >>
Re: Remove Jackson from ActiveMQ classic
Yes I remember the discussion. To be honest, as I was mentioning, even JSON-B/P is probably overkill for what we need. Happy to craft up a PR so we can it discuss there and see if that is feasible for 5.19.x -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Tue, May 16, 2023 at 3:37 PM Matt Pavlovich wrote: > Hello Jean-Louis- > > This has come up in the past. Iirc, the discussion was leaning towards > using json-b and then Jackson as the out-of-the-box provider. > > This sounds like a good change for 5.19.x line > > Thanks, > -Matt Pavlovich > > > On May 16, 2023, at 5:17 AM, Jean-Louis Monteiro < > jlmonte...@tomitribe.com> wrote: > > > > Hi all, > > > > Jackson seems to be frequently affected by CVEs and it's really a pain > for > > users. > > > > Looks like Jackson is only used in the WebConsole to read/write a few > > attributes. I'm sure we can get rid of it and either use a standard API > so > > one can plugin any implementation, or just write down a utility class to > > parse the small attribute we have to. > > > > thoughts? > > > > I'm happy to do a PR to remove it if that's the consensus. > > > > -- > > Jean-Louis Monteiro > > http://twitter.com/jlouismonteiro > > http://www.tomitribe.com > >
Re: Remove Jackson from ActiveMQ classic
Hello Jean-Louis- This has come up in the past. Iirc, the discussion was leaning towards using json-b and then Jackson as the out-of-the-box provider. This sounds like a good change for 5.19.x line Thanks, -Matt Pavlovich > On May 16, 2023, at 5:17 AM, Jean-Louis Monteiro > wrote: > > Hi all, > > Jackson seems to be frequently affected by CVEs and it's really a pain for > users. > > Looks like Jackson is only used in the WebConsole to read/write a few > attributes. I'm sure we can get rid of it and either use a standard API so > one can plugin any implementation, or just write down a utility class to > parse the small attribute we have to. > > thoughts? > > I'm happy to do a PR to remove it if that's the consensus. > > -- > Jean-Louis Monteiro > http://twitter.com/jlouismonteiro > http://www.tomitribe.com
Remove Jackson from ActiveMQ classic
Hi all, Jackson seems to be frequently affected by CVEs and it's really a pain for users. Looks like Jackson is only used in the WebConsole to read/write a few attributes. I'm sure we can get rid of it and either use a standard API so one can plugin any implementation, or just write down a utility class to parse the small attribute we have to. thoughts? I'm happy to do a PR to remove it if that's the consensus. -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com
