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
