James.Strachan wrote: > > 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). >
<include/> tags are the first approach I tried. This is just a mechanism to split up activemq.xml for manageability. The problem is that not every ApplicationContext is formed by loading from XML files. We use a mix of java and xml to create the AC we want to use. See below for more on non-XML AC configuration. James.Strachan wrote: > > 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. > Sure. But then you don't get the nice activemq admin scripts and startup model. We could always start everything ourselves and effectively embed activemq in our app rather than the other way around. James.Strachan wrote: > > 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 > I guess it depends on what you mean by "normal" spring. Parent/child relationships between ACs are pretty powerful and I'd call them normal. Lots of people are using mechanisms besides XML to configure their ACs now. I think you'll see non XML mechanisms for AC configuration becoming much more common. The grails/groovy spring builder comes to mind, as does the spring java config project. Parent/child contexts are a natural way to mix AC's together that are defined in different ways. In some sense, by only allowing XML AC's you are fighting against the full power of Spring. I'm surprised you didn't like adding CamelContextFactoryBean.setParentApplicationContext() This would let you inject your parent using nothing more than simple XML. You could just add <property name="parentApplicationContext" ref="myCustomApplicationContext" /> or leave it blank to match current behavior. No xbean hacking is involved. -- View this message in context: http://www.nabble.com/Controlling-the-ApplicationContext-used-by-a-RouteBuilder-tp17594236s22882p17656860.html Sent from the Camel - Users mailing list archive at Nabble.com.
