camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Controlling the ApplicationContext used by a RouteBuilder
Date Tue, 03 Jun 2008 06:07:48 GMT
2008/6/3 bwtaylor <>:
> I'd still need the activemq.xml to start my ApplicationContext, as I want
> it's lifecycle coupled to that of ActiveMQ and effectively embedded within
> ActiveMQ. I suppose I could do by simply putting a factory bean for it in
> activemq.xml.

You can also add <include/> tags to include other spring.xml files
inside the activemq.xml if you want. Plus if you need it you can split
routes between different spring XML files. (e.g. have a camelContext
in each spring.xml defining some routes).

>I liked the idea of my AC being the parent of the one created
> by ActiveMQ, so that you still could put xml routes in activemq.xml with the
> combined registry.

Note that the activemq.xml is just a spring AC; you can create them
however you wish without the need to create new factory beans or hack
XBean or Spring or whatever.

e.g. just run the <broker> inside any spring.xml / AC you like.

For the dependency stuff, just make sure you use the depends attribute
on the beans that define the JMS ConnectionFactory etc.

>  I already tried it by subclassing
> XBeanBrokerFactory.createApplicationContext(String uri) to call my parent
> locator class followed by new ResourceXmlApplicationContext(resource,
> parent). This solves my problem but isn't generalizable because I have to
> import my specific locator. It's not particularly elegant, but it works.
> Interestingly,  ResourceXmlApplicationContext does implement
> ConfigurableApplicationContext which gives the setParent() method, so there
> might be a way to combine our ideas. CamelContextFactoryBean could support
> setParentApplicationContext() injected from the activmq.xml Context and then
> it could use the combined (adopted?) AC if the child can be cast to
> ConfigurableApplicationContext and a parent exists.
> Actually, ConfigurableApplicationContext might be better a better interface
> to use generally, since your implementation already conforms to it, and it
> also allows you to add application listeners, to add both flavors of post
> processors,  to refresh, and to add shutdown hooks. Application listeners
> and refresh both seem very valueable. If this interests you, let me know, as
> I'd be willing to send in patches.

FWIW we're generally trying to move away from hacking XBean and
relying more on the standard Spring stuff now (and the Spring 2
namespace handler stuff) so I'd rather a solution that works with
normal Spring


Open Source Integration

View raw message