2008/6/3 bwtaylor <[EMAIL PROTECTED]>: > > 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 -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
