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. 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. 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. James.Strachan wrote: > > Why not put the <camelContext ...> <package> elements into your other > spring XML file? (i.e. remove the package element from the activemq.xml) > -- View this message in context: http://www.nabble.com/Controlling-the-ApplicationContext-used-by-a-RouteBuilder-tp17594236s22882p17613713.html Sent from the Camel - Users mailing list archive at Nabble.com.
