activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael André Pearce <michael.andre.pea...@me.com>
Subject Re: [DISCUSS] Custom Object Serialisation Support
Date Fri, 02 Jun 2017 19:22:35 GMT
I agree i much the original proposal to make it a plugin interface, but would want also buy-in
on the qpid jms client also. 



> On 2 Jun 2017, at 19:29, Clebert Suconic <clebert.suconic@gmail.com> wrote:
> 
> Lets start over?
> 
> The easiest thing so far is to make SerializationProvider a pluggable
> interface on ActiveMQConnectionFactory (Maybe on the RA): with
> defaulted to the current serialization.
> 
> 
> https://gist.github.com/clebertsuconic/1b51bb81035db09a8c4177e3d04ac4ae
> 
> 
> We can later see if we create other providers...
> 
> Different than when this was being tried with ActiveMQ a few years
> ago, a lot of things have happened ever since... Serialization sucked
> back in 2005, it sucks even worse now...
> 
> I would rather have a better alternative than having people using
> other tools just because the API is simpler somewhere else...
> 
> 
> It's fairly simple to provide an alternative...
> 
> 
> And I always believe in doing things by steps.. first achievable step
> now is to make this pluggable in ActiveMQ Artemis.. then we see what
> we can do next... just my take on this.
> 
> On Fri, Jun 2, 2017 at 1:26 PM, Michael André Pearce
> <michael.andre.pearce@me.com> 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?
>> 
>> Sent from my iPhone
>> 
>>>> On 2 Jun 2017, at 18:20, Timothy Bish <tabish121@gmail.com> 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 <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/
>>> 
> 
> 
> 
> -- 
> Clebert Suconic

Mime
View raw message