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 <[email protected]> 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 > <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>>>> <[email protected]> wrote: >>>>>>> On Fri, Jun 2, 2017 at 5:26 AM, Martyn Taylor <[email protected]> >>>>>>> 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
