You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Jonathan Gallimore <jo...@gmail.com> on 2021/01/28 10:34:06 UTC
Using JSON-B in ActiveMQ
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
Re: Using JSON-B in ActiveMQ
Posted by Francois Papon <fr...@openobject.fr>.
Very good idea, +1 for me :)
regards,
François
fpapon@apache.org
Le 28/01/2021 à 12:36, Jean-Baptiste Onofre a écrit :
> 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 <jo...@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
Re: Using JSON-B in ActiveMQ
Posted by Jonathan Gallimore <jo...@gmail.com>.
Assuming that this list of where Jackson is used is correct, I would agree
that we could probably do something simpler.
* DestinationsViewFilter
* PartitionBrokerPlugin
* ZooKeeperPartitionBroker
* Partition & Target classes
* PersistenceAdapterView
There's a couple of drivers for asking for this:
* When embedding ActiveMQ in an app server (TomEE in my case, I still think
its a cool feature, so thanks to ActiveMQ for such an awesome project that
enables that happen!) its nice to be able to use the JSON implementation in
the server and not have 2 set of libraries that do the same thing.
* Jackson seems to continually have CVEs associated with it - the
maintainers do a good job of patching it and getting releases out there,
but it would be nice to be able to explore alternatives.
As a recap, Romain previously suggested JSON-B over Jackson, and there was
some resistance to this, but it seemed like using JSON-B would be ok if
Jackson could still be the default implementation. Here's the original
conversation on the JIRA: https://issues.apache.org/jira/browse/AMQ-7072
Is there more appetite for moving to a simplified JSON reader/writer over
using Jackson?
Thanks,
Jon
On Mon, Oct 10, 2022 at 3:56 PM Matt Pavlovich <ma...@gmail.com> wrote:
> 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.gallimore@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.gallimore@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.gallimore@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 <ma...@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 <jb...@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.gallimore@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
> >>>>>
> >>>>
> >>>>
>
>
Re: Using JSON-B in ActiveMQ
Posted by Matt Pavlovich <ma...@gmail.com>.
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 <jo...@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.gallimore@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.gallimore@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 <ma...@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 <jb...@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.gallimore@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
>>>>>
>>>>
>>>>
Re: Using JSON-B in ActiveMQ
Posted by Jonathan Gallimore <jo...@gmail.com>.
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.gallimore@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.gallimore@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 <ma...@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 <jb...@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.gallimore@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
>>> >
>>>
>>>
Re: Using JSON-B in ActiveMQ
Posted by Jonathan Gallimore <jo...@gmail.com>.
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.gallimore@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 <ma...@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 <jb...@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.gallimore@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
>> >
>>
>>
Re: Using JSON-B in ActiveMQ
Posted by Jonathan Gallimore <jo...@gmail.com>.
Thanks for the feedback - I'll look at this targeting 5.17!
Jon
On Thu, Jan 28, 2021 at 6:32 PM Matt Pavlovich <ma...@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 <jb...@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.gallimore@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
> >
>
>
Re: Using JSON-B in ActiveMQ
Posted by Matt Pavlovich <ma...@gmail.com>.
+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 <jb...@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 <jo...@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
>
Re: Using JSON-B in ActiveMQ
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <jo...@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