Makes sense to maybe have a sub project under activemq for these maybe? And move the pooled factory there also?
Sent from my iPhone > On 2 Jun 2017, at 20:15, Timothy Bish <[email protected]> wrote: > >> On 06/02/2017 01:26 PM, Michael André Pearce 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? > > Since it seems you are making something that's not a camel component then I > doubt it would be accepted at Camel. > > As for putting something into Artemis then some questions to ask would be: > > 1. If it is generic then does it make sense to tie it to Artemis where the > perception would be that it is not. > 2. Would you prefer to tie the release cycle of said project to the Artemis > release cycle or would it be better to live on its own where quick bug fix > releases could happen outside the normal broker release process. > > I'd asked the same questions if moving the JMS Pool from ActiveMQ 5.x to > Artemis was proposed, just to clarify that I'm not trying to be unfair. > >> >> 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/ >>> > > -- > Tim Bish > twitter: @tabish121 > blog: http://timbish.blogspot.com/ >
