cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Cohen <sco...@javactivity.org>
Subject Re: Runtime CXF configuration WITHOUT using Spring
Date Fri, 12 Dec 2008 14:01:52 GMT
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 <scohen@javactivity.org> 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
>>>
>>>
>>>       
>>     
>
>
>   


Mime
View raw message