Re: Remove Jackson from ActiveMQ classic

2023-05-16 Thread Jean-Baptiste Onofré
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

Re: Remove Jackson from ActiveMQ classic

2023-05-16 Thread Justin Bertram
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

Re: Remove Jackson from ActiveMQ classic

2023-05-16 Thread Christopher Shannon
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

Re: Remove Jackson from ActiveMQ classic

2023-05-16 Thread Jean-Baptiste Onofré
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

Re: Remove Jackson from ActiveMQ classic

2023-05-16 Thread Jean-Louis Monteiro
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

Re: Remove Jackson from ActiveMQ classic

2023-05-16 Thread Matt Pavlovich
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

Re: Remove Jackson from ActiveMQ classic

2023-05-16 Thread Jean-Louis Monteiro
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

Re: Remove Jackson from ActiveMQ classic

2023-05-16 Thread Matt Pavlovich
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

Remove Jackson from ActiveMQ classic

2023-05-16 Thread Jean-Louis Monteiro
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