You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by "jason.parr" <ja...@usa.net> on 2011/09/15 12:27:56 UTC
Re: Using PropertiesComponent
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.
Re: Using PropertiesComponent
Posted by "jason.parr" <ja...@usa.net>.
Thanks.
In the end I wrote I equivalent bean to PropertiesComponet using
PropertyPlaceholderConfigurer which both use the same shared code for
obtaining properties from an external source.
The only downside is that you need to declare two property resolvers beans
if you want a property to span both camel & springs contexts, plus the
properties get loaded twice. Not a big deal and keeps things simple.
--
View this message in context: http://camel.465427.n5.nabble.com/Using-PropertiesComponent-tp4299191p4807142.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Using PropertiesComponent
Posted by bvahdat <ba...@swissonline.ch>.
Hi Jason,
see:
http://camel.apache.org/how-do-i-use-spring-property-placeholder-with-camel-xml.html
and the ticket Claus talked about is this one (Reporter is James Strachan):
https://jira.springsource.org/browse/SPR-4466
Regards, Babak
--
View this message in context: http://camel.465427.n5.nabble.com/Using-PropertiesComponent-tp4299191p4806495.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Using PropertiesComponent
Posted by "jason.parr" <ja...@usa.net>.
Yes understand but it not a single properties file it's code to load a
hierarchy of properties.
And I can't find the post your talking about as mentioned before, I may have
missed something but could you reference the post's url?
>>>ie 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-tp4299191p4806418.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Using PropertiesComponent
Posted by Claus Ibsen <cl...@gmail.com>.
On Thu, Sep 15, 2011 at 12:27 PM, jason.parr <ja...@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: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Using PropertiesComponent
Posted by "Preben.Asmussen" <pr...@dr.dk>.
year - that's a weak point. I end up using a mix of Spring and Camel
properties whenever the properties file contains a dynamic reference e.g.
environment variable reference.
At the moment I define <Endpoint> elements in the camel context to be able
to use Spring property placeholders, but it's not the nicest solution to
have this kind of mix.
Example:
<camelContext id="GallupFTPContext"
xmlns="http://camel.apache.org/schema/spring">
<endpoint id="ftpTempDirEP" uri="file:${ftptempdir}"/>
<endpoint id="cleanUpEP"
uri="file:${targetdirectory}?delete=true&delay=24h&filter=#oldFilesFilter"/>
<route id="gallupFTPRoute">
<from
uri="ftp://{{ftpuser}}:{{ftppw}}@ftp.server/Rawdata?binary=true&disconnect=true&stepwise=false&delay={{ftppolldelay}}&filter=#ftpFilter"
/>
<log message="Copying ${file:name} to the ftp directory"
logName="com.log.name" loggingLevel="TRACE" />
<to ref="ftpTempDirEP" />
</route>
.........
--
View this message in context: http://camel.465427.n5.nabble.com/Using-PropertiesComponent-tp4299191p4806381.html
Sent from the Camel - Users mailing list archive at Nabble.com.