camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: Appropriate use case for Camel?
Date Fri, 06 Jul 2007 07:02:25 GMT
On 7/5/07, Paul Dlug <paul.dlug@gmail.com> wrote:
> On 7/3/07, James Strachan <james.strachan@gmail.com> wrote:
> > On 7/3/07, Paul Dlug <paul.dlug@gmail.com> wrote:
> > > On 7/3/07, James Strachan <james.strachan@gmail.com> wrote:
> > > > On 7/3/07, James Strachan <james.strachan@gmail.com> wrote:
> > > > > On 7/3/07, Paul Dlug <paul.dlug@gmail.com> wrote:
> > > > > > Hopefully this is an easy answer. I'm a bit unclear on how Camel
> > > > > > should actually be used. I'm currently using ActiveMQ to do
some basic
> > > > > > integration between applications in Java, Ruby, Perl, primarily
via
> > > > > > STOMP. I'd like to use Camel to apply some of the enterprise
> > > > > > integration patterns, especially as it applies to routing as
well as
> > > > > > using some of the built in connectors. From a quick read through
the
> > > > > > docs it appears that I need to build Camel into an application
itself
> > > > > > (in a servlet container or via spring). Is it possible to just
run
> > > > > > Camel inside an ActiveMQ server to configure queues and handle
routing
> > > > > > and other patterns?
> > > > >
> > > > > Absolutely! Actually its on my list of things to do to provide some
> > > > > examples of how to drop camel into the activemq.xml file.
> > > >
> > > > Actually it turned out to be way easier than I thought!
> > > >
> > > > http://cwiki.apache.org/ACTIVEMQ/enterprise-integration-patterns.html
> > > >
> > > > So you could just download tomorrows 5.0 snapshot and you're good to go...
> > >
> > > Thanks James! I've been building 5.0 from subversion anyway so I just
> > > updated my local copy and I'll give this a shot.
> >
> > Great! Let us know how you get on & if there's anything we can do to
> > make it easier to use Camel from inside the ActiveMQ broker
>
> Perhaps I'm still a bit unclear on how to use this, I specified the
> following config:
>
>   <camelContext id="camel"
> xmlns="http://activemq.apache.org/camel/schema/spring">
>     <route>
>       <from uri="queue:a"/>
>       <to uri="queue:b"/>
>     </route>
>   </camelContext>
>
> Which as I understand it should take messages addressed to the queue
> "a" and send them to "b".

Unfortunately not; the "queue: " URI currently in Camel talks to an
in-memory queue. There's a note here

http://activemq.apache.org/camel/queue.html

I'm thinking to avoid further confusion we should rename this
component to be called "seda:" or something instead to avoid
confusion.


> This doesn't seem to actually work though,
> I've tried changing the endpoints from "queue:a" to "activemq:a" but
> that didn't seem to help. Any tips for a newbie?

So I just tried it with the latest trunk. I uncommented the route
thats in there & browsed the queue ("example.A) and it was created
with a single consumer. Though when I sent a message to it I got a
stack trace in the broker log with a ClassNotFoundException.

It turned out that the binary distro should be copying the JTA jar
from J2EE into the lib directory; but it wasn't. I've just fixed that,
so it seems to be working for me. Incidentally I've changed trunk to
enable the camel route by default to make it easier to try out

So these steps should work

* grab trunk & build it
* boot up the broker
* view the web console at http://0.0.0.0:8161/admin
* go to the queues tab
* you should now see an empty "example.A" queue
* try send some messages to this queue (there's a Send To link on the right)
* in a second or so hit refresh on the queues view; you should now see
the "example.B" queue with the message inside, with the example.A
queue now being empty




> Another question I have is, how do I reload new definitions without
> restarting? I've I'd like to change destinations or filtering how can
> I do that on the fly and be sure I'm not dropping any messages?

So rules defined in a Spring.xml file can be reloaded on change of the
XML file; if you want to redeploy your rules on the fly, you might
wanna boot up a separate spring application context with just the
rules inside (so that the broker isnt' redeployed too). e.g. create a
WAR or stand alone Java program with your rules so they can be
re-loaded on the fly without restarting your broker

-- 
James
-------
http://macstrac.blogspot.com/

Mime
View raw message