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