Yrs ago we ended up writing a camel wrapper when camel went from v1.x to 2.x and the camel api change broke apps that were written to the camel 1.x api.
Dont extend/wrap camel. Its was ok for a short period of time, but required maint. over time. suggestion : either just use the camel api or the jms api in your app. Andy On Fri, 2017-06-02 at 18:26 +0100, 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? > > 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 <mtaylor@redh > > > > > > at.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/ > >
smime.p7s
Description: S/MIME cryptographic signature
