Do we really need a full JSON stack *in* the broker? Could we not move to some simplified JSON writers (like what Log4j2 does)? Or model class toString() r util method implementations that write out valid JSON?
-Matt > On Oct 10, 2022, at 9:46 AM, Jonathan Gallimore > <jonathan.gallim...@gmail.com> wrote: > > Hi > > Are there any thoughts on this (even if its a hard no, or a different view > on how it might be implemented)? > > Thanks > > Jon > > On Tue, May 10, 2022 at 11:25 AM Jonathan Gallimore < > jonathan.gallim...@gmail.com> wrote: > >> When I originally posted, my hope was that Jackson might be able to >> implement JSON-B itself. Almost a year on, that feels like it would still >> be my favourite approach, but is possibly not realistic. Would the >> community be open to an abstraction in ActiveMQ allowing either Jackson, or >> a JSON-B implementation to be used? >> >> I'm thinking along the lines of JAX-RS' MessageBodyReader / >> MessageBodyWriter - this could be interesting as there has been a proposal >> to use it for handling JSON-based messages in Jakarta Messaging: >> https://github.com/jakartaee/messaging-proposals/tree/master/jsonb-messages/proposal1 >> >> The thought here would be to have two implementations of >> MessageBodyReader/MessageBodyWriter (one for Jackson - the default), one >> that delegates to JSON-B), and use whichever is configured. It looks like >> there are a few places we'd need to do this: >> >> * DestinationsViewFilter >> * PartitionBrokerPlugin >> * ZooKeeperPartitionBroker >> * Partition & Target classes >> * PersistenceAdapterView >> >> Does that list sound right, or is there functionality I'm missing in that >> list? Does the abstraction sound reasonable, or would you not be in favor? >> >> Thanks >> >> Jon >> >> On Tue, Feb 2, 2021 at 11:38 AM Jonathan Gallimore < >> jonathan.gallim...@gmail.com> wrote: >> >>> Thanks for the feedback - I'll look at this targeting 5.17! >>> >>> Jon >>> >>> On Thu, Jan 28, 2021 at 6:32 PM Matt Pavlovich <mattr...@gmail.com> >>> wrote: >>> >>>> +1 JSON-B using Jackson and targeting 5.17.x >>>> >>>> Given the popularity of pairing ActiveMQ w/ Camel and CXF, I think >>>> staying with Jackson is a good idea and would cause less volatility. >>>> >>>>> On Jan 28, 2021, at 5:36 AM, Jean-Baptiste Onofre <j...@nanthrax.net> >>>> wrote: >>>>> >>>>> Hi Jon, >>>>> >>>>> Clearly +1 for me to go using JSON-B. >>>>> >>>>> However, I will focus this for 5.17.x. I’m working on cleanup, update, >>>> etc for this version, so I think it’s the good timing to use JSON-B. >>>>> >>>>> So, +1 to use master (5.17.x) for that. If you can wait a bit, I can >>>> merge the first round cleanup (removing leveled, etc). >>>>> Else, go ahead, we will rebase. >>>>> >>>>> My +1 >>>>> >>>>> Regards >>>>> JB >>>>> >>>>>> Le 28 janv. 2021 à 11:34, Jonathan Gallimore < >>>> jonathan.gallim...@gmail.com> a écrit : >>>>>> >>>>>> Hi All >>>>>> >>>>>> Just to introduce myself a little, I am one of the contributors to >>>> Apache >>>>>> TomEE, and we have been embedding ActiveMQ 5 for some time, and have >>>> found >>>>>> it a really nice solution, in particular enabling users to work with >>>> JMS >>>>>> with almost no setup. >>>>>> >>>>>> We do have a desire to slim down our dependencies, and I would like to >>>>>> propose that ActiveMQ potentially use JSON-B as opposed to being >>>> tightly >>>>>> coupled to one specific JSON parsing library. >>>>>> >>>>>> This has previously been discussed on >>>>>> https://issues.apache.org/jira/projects/AMQ/issues/AMQ-7072, and it >>>> sounded >>>>>> like the community was open to using JSON-B, but would strongly want >>>> to >>>>>> stick with Jackson as the default serializer. >>>>>> >>>>>> I'd like to have a go at working on this. If I was able to make the >>>> change >>>>>> to use JSON-B, (and I appreciate that may need work here (which I'm >>>> also ok >>>>>> to contribute to): >>>>>> https://github.com/FasterXML/jackson-future-ideas/issues/19. If I >>>> could do >>>>>> this, and keep Jackson as the default serializer, would this be a >>>>>> contribution that the community could consider? >>>>>> >>>>>> Many thanks >>>>>> >>>>>> Jon >>>>> >>>> >>>>
