Thanks, Ian, for this cogent explanation.
This is exactly what I need to know and it sounds like it will work. I
didn't understand the whole
<property name="locations">
<list>
<value>classpath:config.properties</value>
</list>
</property>
construct. I hadn't understood what the "locations" property was for and
didn't realize that I could put a file url there instead. This looks like exactly what I
want, now that you've explained it. A better name might have been configLocations or
something but that's how it goes.
Since locations can evidently take a list of possible values, am I to assume
that this list is ordered and that I could define strategy of standard
configurations with possible overridables for us in a development setting? If
so, am I correct in presuming that the first item in the list is the first to
be searched, so that the defaults would go on the bottom?
Well, you've made my day. I think I must go and read the source of
PropertyPlaceHolderConfigurer.java and figure all this out for myself.
Basically I've been trying to roll my own version of this kind of setup for a
long time.
Ian Roberts wrote:
Steve Cohen wrote:
But I don't completely understand yet. Okay, let's say I make the small
step of putting the PropertyPlaceHolderConfigurer into my cxf.xml
file. How does the PropertyPlaceHolderConfigurer know where to find my
config.properties files? We get into these chicken and egg problems.
The location is set in the <bean> block that sets up the configurer
within cxf.xml:
<bean id="propertyConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<list>
<value>classpath:config.properties</value>
</list>
</property>
</bean>
classpath:config.properties means it looks for config.properties on your
classpath (i.e. in WEB-INF/classes). You could put an absolute file URL
in there instead (file:///home/me/config.properties) if you want it to
load from a fixed location rather than from inside your webapp.
It's also worth noting that a PropertyPlaceholderConfigurer will use
Java system properties if it can't find the relevant entry in
config.properties, i.e. if you have a ${webservice.username} placeholder
in your cxf.xml but no webservice.username=blah in config.properties
then it will look at the Java system property with the same name. If
you *only* want to resolve system properties and not bother with
config.properties at all then you could just use:
<bean id="propertyConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"
/>
Ian
