Exactly. I'm not really OPPOSED to Spring, I just don't have time to
rearchitect a substantial application. But if CXF is forcing me to
include the Spring jars, and I can get other benefits of Spring from
these jars without rearchitecting, I'm not going to look that gift horse
in the mouth. Rearchitecting can come later, when I have time, and I
guess it's nice to know that Spring can be used piecemeal like this
unlike some other "Frameworks" out there that make you bend to their
idea of how things ought to be.
Benson Margulies wrote:
There has been a fairly serious case of 'who's on first?' going on here?
Or, to paraphrase Voltaire, "Steve didn't know that he was already
speaking in Spring."
If Steve really wanted to be Spring-free, he'd need to tear down the
use of the CXFServet's standard Spring-y behavior and build up his
service from the API himself. On the other hand, my impression is that
now that he realizes the non-impact of how Spring plays out in the
servlet, he's gone over to the dark side.
On Fri, Dec 12, 2008 at 8:23 AM, Steve Cohen <[email protected]> wrote:
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
