activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clebert Suconic <clebert.suco...@gmail.com>
Subject Re: [DISCUSS] Custom Object Serialisation Support
Date Fri, 02 Jun 2017 15:08:27 GMT
You know what would be cool IMO?

Create a camel-jms-tool / camel-jms-wrapper (whatever the name you need):

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.



-- 
Clebert Suconic

Mime
View raw message