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

Reply via email to