You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by jpalmer1026 <pa...@gmail.com> on 2011/04/12 23:38:43 UTC

Using PropertiesComponent

Hi,

I have a properties bean defined in my Spring application context file that
I use to specify the location of an externalized property file. The problem
I'm having is that I need to reference properties contained in the
externalized property file from a bean defined in the Spring application
file. So far the only way I'm been able to do this is to use a
context:property-placeholder tag as well as a Camel PropertiesComponent
bean.

Is there a way to use just the Camel PropertiesComponent bean without
requiring the context:property-placeholder tag?

--
View this message in context: http://camel.465427.n5.nabble.com/Using-PropertiesComponent-tp4299191p4299191.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Using PropertiesComponent

Posted by jpalmer1026 <pa...@gmail.com>.
Hi Claus,

Thanks for the explanation. That's sort of a bummer that the
context:property-placeholder tag is required. Not a huge deal or anything,
just not as DRY (don't repeat yourself) as it could be.

You asked how I reference the property from the bean. I do that just by
following normal Spring conventions in that my bean's property tag value
attribute uses the ${} notation to reference the property defined in the
context:property-placeholder tag.



--
View this message in context: http://camel.465427.n5.nabble.com/Using-PropertiesComponent-tp4299191p4300659.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&amp;delay=24h&amp;filter=#oldFilesFilter"/>
		
		<route id="gallupFTPRoute">
			<from
uri="ftp://{{ftpuser}}:{{ftppw}}@ftp.server/Rawdata?binary=true&amp;disconnect=true&amp;stepwise=false&amp;delay={{ftppolldelay}}&amp;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.

Re: Using PropertiesComponent

Posted by "jason.parr" <ja...@usa.net>.
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 Claus Ibsen <cl...@gmail.com>.
On Tue, Apr 12, 2011 at 11:38 PM, jpalmer1026 <pa...@gmail.com> wrote:
> Hi,
>
> I have a properties bean defined in my Spring application context file that
> I use to specify the location of an externalized property file. The problem
> I'm having is that I need to reference properties contained in the
> externalized property file from a bean defined in the Spring application
> file. So far the only way I'm been able to do this is to use a
> context:property-placeholder tag as well as a Camel PropertiesComponent
> bean.
>
> Is there a way to use just the Camel PropertiesComponent bean without
> requiring the context:property-placeholder tag?
>

If you use any of the Spring properties support then you need
context:property-placeholder. SpringSource guys are not very friendly
to make it easy for 3rd party to influence the placeholder code. There
has been a JIRA for more then 3+ years about that. See the Camel FAQ.

However there was a person in this forum which posted a way of doing a
"delegate" using a bit more ugly <bean> style. Where you define a
custom <bean> that wraps the spring property placeholder and bridge
that with Camel.

We could reconsider that and maybe try to add some nicer way if that
would be possible.


BTW how do you reference that property from your bean?
We have considered adding a Camel annotation to reference a Camel
property. But I assume ppl would rather use a Spring annotation or
something from the JDK if possible. It would be neat if there was a
standard annotation 3rd party frameworks could rely on.



> --
> View this message in context: http://camel.465427.n5.nabble.com/Using-PropertiesComponent-tp4299191p4299191.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
CamelOne 2011: http://fusesource.com/camelone2011/
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/