I'm using Spring. PropertyPlaceholder magic makes Spring config vary based on deployment.
At a high level, the recipe is as follows. RouteBuilder rather than SpringRouteBuilder as parent class would work fine unless you want to call things like beanRef() instead of bean(). @Component //make sure route builder gets instantiated class ... extends SpringRouteBuilder { @Autowired / @Resource ... to pull in configuration from Spring @PostConstruct public void init() throws Exception { //if needed, register stuff: this.camelContext.addComponent("jms-opps", this.amqc); //finally, hook into Camel context: this.camelContext.addRoutes(this); } Cheers -Lorrin On Sep 22, 2010, at 1:41 PM, David Yang wrote: > > I'm curious how others are solving the problem of managing configuration > across various routes, components etc inside a Camel Context. > > We've written some Components that themselves need to have connections to > various DB's etc. If we want to have a development and production properties > for each one of those (so that they can be individually run/tested) but then > use those Components in separate Route projects and a master CamelContext, > what would you recommend. They have other dependencies as well (directory > locations, file resources, application binaries). > > Basically, if this is my world, where should I keep all the configuration > properties? > > Master Context > - Route 1 > - Comp A > - Comp B > - Route 2 > - Comp A' (A with diff configuration) > - Comp C > > I've thought about using JNDI, Jconfig or having some huge overwritable map > Singleton. Any thoughts/ideas? Would really like hearing how others are > solving this. > > David > >