2008/6/4 bwtaylor <[EMAIL PROTECTED]>: > > > 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.
Sorry I misunderstood; I thought you meant hacking XBean :) Oh sure, specifying the parent applicationContext on the camel context factory bean is fine. I just wanted to check what you wanted the CamelContextFactoryBean to do with the parent applicationContext its given? BTW I'm still not quite sure why you couldn't just have this inside activemq.xml <include uri="myroutes.xml"/> then in myroutes.xml have a <camelContext> and whatever other routes you want? -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
