activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Bish <>
Subject Re: [DISCUSS] Custom Object Serialisation Support
Date Fri, 02 Jun 2017 17:20:38 GMT
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 

> Sent from my iPhone
>> On 2 Jun 2017, at 18:04, Timothy Bish <> wrote:
>>> 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 need):
>> 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 the
>>>>> (de)serialization process for performance or security reasons, whilst
>>>>> controlling data format.  I still think having something light weight
>>>>> 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
>>>>> the client to do it.
>>>> I think so... Camel will .. as far as I know.. will make you commit
>>>> the consumer and do an ack on every message received like MDBs do...
>>>> Introducing Camel just for the sake of serialization doesn't seem the
>>>> right decision to me.. there's a lot more interesting on Camel than
>>>> just the serialization mechanism.
>>>>> But, if this thread is really only about integrating multiple technologies,
>>>>> by controlling bytes that are sent over the wire then I have to agree
>>>>> Tim, in that Camel does seem to be a good fit for this problem.  Michael,
>>>>> 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 serialization
>>>>> 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

View raw message