On Thu, Sep 15, 2011 at 12:27 PM, jason.parr <jason.p...@usa.net> wrote: > > We had assumed that camel's PropertiesComponent resolution would be visible > within the general Spring context and wrote our own camel PropertiesResolver > to walk a complex hierarchical tree of config. > > This all works fine with the camel world but falls flat on it's face when > trying to resolve standard spring properties. > > You mentioned a post that came up with delegate work around - I've searched > for the post but can't find it. > > We don't want to have two different mechanisms for resolving our properties > so it's either the delegate approach or rewrite to use springs standard > mechanism. > > This has turned out to be quite an unexpected blocker in moving our code > from dev to uat/prod - I think the PropertiesComponent doco should highlight > this caveat more strongly. >
Just declare them both spring + camel and refer to the same .properties file(s). The problem is SpringSource not listening to the community and doing anything about that SPR jira ticket report so many years ago and having many votes. Alternatively is to use that delegate spring bean that a Camel community member posted on this forum. > -- > View this message in context: > http://camel.465427.n5.nabble.com/Using-PropertiesComponent-tp4299191p4806335.html > Sent from the Camel - Users mailing list archive at Nabble.com. > -- Claus Ibsen ----------------- FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
