activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Bentley <abent...@ll.mit.edu>
Subject Re: [DISCUSS] Custom Object Serialisation Support
Date Fri, 02 Jun 2017 17:49:03 GMT
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 <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@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/
> > 
Mime
View raw message