activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Bish <tabish...@gmail.com>
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 
JMS'y?

> Sent from my iPhone
>
>> On 2 Jun 2017, at 18:04, Timothy Bish <tabish121@gmail.com> 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
>>> <clebert.suconic@gmail.com> wrote:
>>>> On Fri, Jun 2, 2017 at 5:26 AM, Martyn Taylor <mtaylor@redhat.com>
wrote:
>>>>> So, I could originally see a requirement for controlling the
>>>>> (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 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
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 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: http://timbish.blogspot.com/
>>

-- 
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/


Mime
View raw message