activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael André Pearce <>
Subject Re: [DISCUSS] Custom Object Serialisation Support
Date Fri, 02 Jun 2017 19:24:00 GMT
Makes sense to maybe have a sub project under activemq for these maybe? And move the pooled
factory there also?

Sent from my iPhone

> On 2 Jun 2017, at 20:15, Timothy Bish <> wrote:
>> On 06/02/2017 01:26 PM, Michael André Pearce wrote:
>> That makes sense to me I agree on that.
>> Do you think it's better to have tools that present jms api like pooled connection
factory and this, sitting in artemis as extensions or in camel project?
> Since it seems you are making something that's not a camel component then I doubt it
would be accepted at Camel.
> As for putting something into Artemis then some questions to ask would be:
> 1. If it is generic then does it make sense to tie it to Artemis where the perception
would be that it is not.
> 2. Would you prefer to tie the release cycle of said project to the Artemis release cycle
or would it be better to live on its own where quick bug fix releases could happen outside
the normal broker release process.
> I'd asked the same questions if moving the JMS Pool from ActiveMQ 5.x to Artemis was
proposed, just to clarify that I'm not trying to be unfair.
>> Sent from my iPhone
>>>> On 2 Jun 2017, at 18:20, Timothy Bish <> wrote:
>>>> On 06/02/2017 01:16 PM, Michael André Pearce wrote:
>>>> Yeas but we just want a JMS Api wrapper that exposes again JMS api, here.
>>> My point being, don't call it camel-x as it isn't camel and would cause confusion.
 Calling it camel-jms-wrapper leads one to believe you've wrapped camel-jms (which is a JMS
wrapper) with a wrapper making it more JMS'y?
>>>> Sent from my iPhone
>>>>>> On 2 Jun 2017, at 18:04, Timothy Bish <>
>>>>>> On 06/02/2017 11:08 AM, Clebert Suconic wrote:
>>>>>> You know what would be cool IMO?
>>>>>> Create a camel-jms-tool / camel-jms-wrapper (whatever the name you
>>>>> Camel already has a JMS wrapper that takes a connection factory, it's
called camel-jms, or if you don't want any spring deps then camel-sjms
>>>>>> Add a couple of tools there:
>>>>>> - The connection factory that we need to share with qpid-jms
>>>>>> - This class that Micahel is writing..
>>>>>> and it would be a nice marriage. This camel-jms-wrapper could be
>>>>>> lightweight and offer not many dependencies on camel itself.
>>>>>> Just brain storming ^^^^
>>>>>> On Fri, Jun 2, 2017 at 10:16 AM, Clebert Suconic
>>>>>> <> wrote:
>>>>>>> On Fri, Jun 2, 2017 at 5:26 AM, Martyn Taylor <>
>>>>>>>> So, I could originally see a requirement for controlling
>>>>>>>> (de)serialization process for performance or security reasons,
whilst also
>>>>>>>> controlling data format.  I still think having something
light weight that
>>>>>>>> gives users control over this (outside of overriding the
java serialization
>>>>>>>> methods) may be useful.  It would only take a couple of lines
of code in
>>>>>>>> the client to do it.
>>>>>>> I think so... Camel will .. as far as I know.. will make you
>>>>>>> the consumer and do an ack on every message received like MDBs
>>>>>>> Introducing Camel just for the sake of serialization doesn't
seem the
>>>>>>> right decision to me.. there's a lot more interesting on Camel
>>>>>>> just the serialization mechanism.
>>>>>>>> But, if this thread is really only about integrating multiple
>>>>>>>> by controlling bytes that are sent over the wire then I have
to agree with
>>>>>>>> Tim, in that Camel does seem to be a good fit for this problem.
 Michael, I
>>>>>>>> can see your point re: the success of the Kafka model, if
you feel that
>>>>>>>> this is largely down to the API and the abstraction of the
>>>>>>>> process, how about just wrapping a Camel context?
>>>>>>> I am not sure what performance implications this would make..
and it
>>>>>>> seems more complicated to be used.
>>>>>>> A simpler API has a higher chance of success.
>>>>> -- 
>>>>> Tim Bish
>>>>> twitter: @tabish121
>>>>> blog:
>>> -- 
>>> Tim Bish
>>> twitter: @tabish121
>>> blog:
> -- 
> Tim Bish
> twitter: @tabish121
> blog:

View raw message