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
>
>