You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Steve Cohen <sc...@javactivity.org> on 2008/12/11 12:44:52 UTC
Runtime CXF configuration WITHOUT using Spring
I have been somewhat reluctantly dragged into using CXF (version 2.0.7)
by deadline pressure and vendor recommendation. I like many things
about it but there are issues. I've ranted about some of these issues
before, but don't want to dredge them up again. I believe it is
overkill for my needs, simply to create a SOAP client to access a
vendor's web service.
Nonetheless, here I am.
I am trying to deploy a CXF-based Web Service client into an
architecture that runs on Tomcat 6.0. We DO NOT at present use the
Spring Framework, although we may look at doing so as time permits, but
time does not permit such an exploration now. I have up to now used an
architectural principle that produces ONE war file that runs on all
tiers (dev, test, production) with differences between tiers resolved at
runtime by properties files, etc.
Our vendor has two systems, one for development and one for production.
Switching endpoints is managed by having CXF load different WSDLs. This
is suboptimal but manageable at runtime, by using properties files, and
needless to say, I don't want to be modifying the vendor's WSDL and
maintaining that over time.
The backbreaker appears to be getting the CXF configuration to load.
This should be simple but it's turning into a nightmare. The vendor
also has given us different credentials for access to the different
tiers of his service and these can only be loaded via the CXF
configuration, apparently.
I can't find any method that allows my application to select the proper
CXF config file at runtime. The only method by which my application is
able to successfully authenticate itself to vendor's service is by
placing the credentials a in file named "cxf.xml" (nothing else will do)
residing on the web app's classpath inside the war file. I have tried
the suggestions at the top of
http://cwiki.apache.org/CXF20DOC/configuration.html, specifically
> CXF can discover XML configuration files which you have written. For
> both web service clients and servers, the default location that CXF
> will look for a configuration for is "/cxf.xml" on the class path. If
> you wish to override this location, you can specify a command line
> property: -Dcxf.config.file=some_other_config.xml. To use a url as the
> configuration location, specify as follows:
> -Dcxf.config.file.url=config_file_url.
and none of them work in my environment. Although my app can see the
system property "cxf.config.file" it does not affect how CXF finds its
configuration. My suspicions are either
1) The advice above does not work in CXF 2.0.7 which is what I am
using. If I can be assured that it fixed in a later release, I might be
tempted to make the switch.
2) This is a bug which does not work at all in any version of CXF.
3) this is another feature of CXF that depends on tighter integration
with Spring (I do have to include its jars but I'm not USING the
framework). This is becoming an annoying theme here - if this is the
reason, you guys might think about naming yourselves Spring XML
Framework. It annoys me that so much advice here assumes I'm using
Spring. If that is a requirement, it needs to be more strongly
advertised in your materials. Hopefully this is not the case.
Can someone please enlighten me as to what is going on here? Switching
between different authentication credentials should not be this hard and
I'm willing to try almost anything at this point other than suggestions
that I migrate to Spring, change my build process, etc. While perhaps
worthwhile, I have no time for such things now.
Re: Runtime CXF configuration WITHOUT using Spring
Posted by Sergey Beryozkin <se...@progress.com>.
Hi
>I have been somewhat reluctantly dragged into using CXF (version 2.0.7) by deadline pressure and vendor recommendation. I like
>many things about it but there are issues. I've ranted about some of these issues before, but don't want to dredge them up again.
>I believe it is overkill for my needs, simply to create a SOAP client to access a vendor's web service.
No problems at all. Hope you'll like it more in some time.
>
> Nonetheless, here I am.
You're welcome :-)
>
> I am trying to deploy a CXF-based Web Service client into an architecture that runs on Tomcat 6.0. We DO NOT at present use the
> Spring Framework, although we may look at doing so as time permits, but time does not permit such an exploration now. I have up
> to now used an architectural principle that produces ONE war file that runs on all tiers (dev, test, production) with differences
> between tiers resolved at runtime by properties files, etc.
>
> Our vendor has two systems, one for development and one for production. Switching endpoints is managed by having CXF load
> different WSDLs. This is suboptimal but manageable at runtime, by using properties files, and needless to say, I don't want to be
> modifying the vendor's WSDL and maintaining that over time.
>
> The backbreaker appears to be getting the CXF configuration to load. This should be simple but it's turning into a nightmare.
> The vendor also has given us different credentials for access to the different tiers of his service and these can only be loaded
> via the CXF configuration, apparently.
here's something which might help you. I believe that might be part of the (CXF )Fuse documentation, but here's some relevant text :
1. Up until cxf-2.0.7, the cxf configuration file should be located in the ${webapp}/WEB-INF/classes for it be picked up by CXF
2. If the cxf configuration file is named 'cxf.xml' then it will be discovered by CXF automatically, otherwise
$tomcathome/bin/catalina batch file needs to be updated with -Dcxf.config.file system property. For ex :
-Dcxf.config.file=client.xml
where the value of -Dcxf.config.file is a location relative to ${webapp}/WEB-INF/classes
3. All resource locations inside the configuration file itself should be relative to ${webapp}/WEB-INF/classes
3. IF configuration file is not located in ${webapp}/WEB-INF/classes, then another option is to programmatically create a bus using
a servlet context api. For ex, if client.xml is located in ${webapp}/WEB-INF/ then the following code will work :
public void init(ServletConfig cfg) {
URL url = cfg.getServletContext().getResource("/WEB-INF/client.xml");
Bus bus = new SpringBusFactory().createBus(url);
BusFactory.setDefaultBus(bus);
}
Would say option 3 work for you ? Inside your own servlet, depending on the some per-request info, you may create a specific Bus,
possibly cache it to be reused for similar subsequent requests ? You won't do it in init() but in get()/post() handlers, and you'll
set BusFactory.setThreadLocalBus(bus); instead for a current thread to continue rely on the chosen configuration ?
If you don't want to hardcode the name of the configuration file you might be able to use ServletConfig ?
Cheers, Sergey
>
> I can't find any method that allows my application to select the proper CXF config file at runtime. The only method by which my
> application is able to successfully authenticate itself to vendor's service is by placing the credentials a in file named
> "cxf.xml" (nothing else will do) residing on the web app's classpath inside the war file. I have tried the suggestions at the top
> of http://cwiki.apache.org/CXF20DOC/configuration.html, specifically
>
>> CXF can discover XML configuration files which you have written. For both web service clients and servers, the default location
>> that CXF will look for a configuration for is "/cxf.xml" on the class path. If you wish to override this location, you can
>> specify a command line property: -Dcxf.config.file=some_other_config.xml. To use a url as the configuration location, specify as
>> follows: -Dcxf.config.file.url=config_file_url.
> and none of them work in my environment. Although my app can see the system property "cxf.config.file" it does not affect how
> CXF finds its configuration. My suspicions are either
>
> 1) The advice above does not work in CXF 2.0.7 which is what I am using. If I can be assured that it fixed in a later release, I
> might be tempted to make the switch.
>
> 2) This is a bug which does not work at all in any version of CXF.
>
> 3) this is another feature of CXF that depends on tighter integration with Spring (I do have to include its jars but I'm not
> USING the framework). This is becoming an annoying theme here - if this is the reason, you guys might think about naming
> yourselves Spring XML Framework. It annoys me that so much advice here assumes I'm using Spring. If that is a requirement, it
> needs to be more strongly advertised in your materials. Hopefully this is not the case.
>
> Can someone please enlighten me as to what is going on here? Switching between different authentication credentials should not be
> this hard and I'm willing to try almost anything at this point other than suggestions that I migrate to Spring, change my build
> process, etc. While perhaps worthwhile, I have no time for such things now.
>
>
Re: Runtime CXF configuration WITHOUT using Spring
Posted by Steve Cohen <sc...@javactivity.org>.
Please see upthread. What I am trying to do was pruned somewhere along
the way. Basically it was to have an application that would configure
itself, based on environmental factors, to find the right cxf.xml file
to contact the proper tier of a vendor's web service (staging,
production, etc.) without having to deploy a lot of files on the server,
i.e. minimize the number of things system operators needed to keep track of.
Daniel Kulp wrote:
> Can I just ask exactly what are you trying to configure in the spring file?
> Just about everything that is configured in spring CAN be done
> programatically via API's. It just may take a bit to find all the API's
> that are needed.
>
> Thus, you MAY be able pull the spring jars out and then use the API's to do
> the configuration. You can keep your configs in any form that is convenient
> to you.
>
> Dan
>
>
> On Thursday 11 December 2008 10:41:11 pm Steve Cohen wrote:
>
>> Thanks. This is intriguing. Of course this involves Spring, which,
>> again, I'm NOT using -- or am I??? My application isn't consciously
>> part of the Spring Framework - but then it does, of course need the
>> Spring libraries for the CXF and cxf.xml is a Spring config file. So
>> tell me - is it possible for me to put my toe in the Spring water
>> without getting my whole body wet? I guess "all wet" would be defined
>> as Spring in web.xml, etc. I can't afford the time to go that deep yet,
>> but if this solves my problem, I could start edging in that direction
>> and maybe (probably, I think) even like it. This approach to runtime
>> environmental configuration is very much in the spirit of my home-grown
>> system only more systematic.
>>
>> 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.
>> Must I have a spring-config.xml to tell it where? And if so, what
>> causes THAT to be loaded?
>>
>> I'm not snarking here. If I can make this work, I think I'll go with
>> it. What is the minimum Spring footprint I need to get this going.
>>
>> Christian Schneider wrote:
>>
>>> Hi Steve,
>>>
>>> there is a nice article that shows how to use the
>>> PropertyPlaceHolderConfigurer.
>>>
>>> http://icoloma.blogspot.com/2008/01/mock-your-spring-config-for-fun-and.h
>>> tml
>>>
>>>
>>> There is no list of passwords and locations. You simply have different
>>> property files for your different environments. For example:
>>>
>>> Develop:
>>> File config.properties
>>> url=http://dev.server.com/service
>>> username=client1
>>> password=mydevpasswd
>>>
>>> Test:
>>> File config.properties
>>> url=http://test.anotherserver/service
>>> username=client1
>>> password=mytestpassword
>>>
>>> Ideally you manage to keep these files separate from your module (war
>>> in your case). So you can deploy a new version by copying the war and
>>> the config stays the same.
>>> I guess you had a quite similar solution with your property files
>>> already?!
>>>
>>> Greetings
>>>
>>> Christian
>>>
>>> Steve Cohen schrieb:
>>>
>>>> Thanks, Christian.
>>>>
>>>> This certainly sounds like it could be the answer to my dilemma and I
>>>> agree wholeheartedly with you that this is a normal scenario that
>>>> needs to be supported.
>>>> However, I don't fully understand what you are suggesting here.
>>>> Something must be a selector (a key) into the list of locations and
>>>> passwords and somehow this key needs to be passed to the object doing
>>>> the resolution. Is there a fleshed out sample of this anywhere?
>>>>
>>>> Steve
>>>>
>
>
>
>
Re: Runtime CXF configuration WITHOUT using Spring
Posted by Daniel Kulp <dk...@apache.org>.
Can I just ask exactly what are you trying to configure in the spring file?
Just about everything that is configured in spring CAN be done
programatically via API's. It just may take a bit to find all the API's
that are needed.
Thus, you MAY be able pull the spring jars out and then use the API's to do
the configuration. You can keep your configs in any form that is convenient
to you.
Dan
On Thursday 11 December 2008 10:41:11 pm Steve Cohen wrote:
> Thanks. This is intriguing. Of course this involves Spring, which,
> again, I'm NOT using -- or am I??? My application isn't consciously
> part of the Spring Framework - but then it does, of course need the
> Spring libraries for the CXF and cxf.xml is a Spring config file. So
> tell me - is it possible for me to put my toe in the Spring water
> without getting my whole body wet? I guess "all wet" would be defined
> as Spring in web.xml, etc. I can't afford the time to go that deep yet,
> but if this solves my problem, I could start edging in that direction
> and maybe (probably, I think) even like it. This approach to runtime
> environmental configuration is very much in the spirit of my home-grown
> system only more systematic.
>
> 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.
> Must I have a spring-config.xml to tell it where? And if so, what
> causes THAT to be loaded?
>
> I'm not snarking here. If I can make this work, I think I'll go with
> it. What is the minimum Spring footprint I need to get this going.
>
> Christian Schneider wrote:
> > Hi Steve,
> >
> > there is a nice article that shows how to use the
> > PropertyPlaceHolderConfigurer.
> >
> > http://icoloma.blogspot.com/2008/01/mock-your-spring-config-for-fun-and.h
> >tml
> >
> >
> > There is no list of passwords and locations. You simply have different
> > property files for your different environments. For example:
> >
> > Develop:
> > File config.properties
> > url=http://dev.server.com/service
> > username=client1
> > password=mydevpasswd
> >
> > Test:
> > File config.properties
> > url=http://test.anotherserver/service
> > username=client1
> > password=mytestpassword
> >
> > Ideally you manage to keep these files separate from your module (war
> > in your case). So you can deploy a new version by copying the war and
> > the config stays the same.
> > I guess you had a quite similar solution with your property files
> > already?!
> >
> > Greetings
> >
> > Christian
> >
> > Steve Cohen schrieb:
> >> Thanks, Christian.
> >>
> >> This certainly sounds like it could be the answer to my dilemma and I
> >> agree wholeheartedly with you that this is a normal scenario that
> >> needs to be supported.
> >> However, I don't fully understand what you are suggesting here.
> >> Something must be a selector (a key) into the list of locations and
> >> passwords and somehow this key needs to be passed to the object doing
> >> the resolution. Is there a fleshed out sample of this anywhere?
> >>
> >> Steve
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: Runtime CXF configuration WITHOUT using Spring
Posted by Steve Cohen <sc...@javactivity.org>.
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 <sc...@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
>>>
>>>
>>>
>>
>
>
>
Re: Runtime CXF configuration WITHOUT using Spring
Posted by Benson Margulies <bi...@gmail.com>.
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 <sc...@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
>>
>>
>
>
Re: Runtime CXF configuration WITHOUT using Spring
Posted by Steve Cohen <sc...@javactivity.org>.
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
>
>
Re: Runtime CXF configuration WITHOUT using Spring
Posted by Ian Roberts <i....@dcs.shef.ac.uk>.
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
--
Ian Roberts | Department of Computer Science
i.roberts@dcs.shef.ac.uk | University of Sheffield, UK
Re: Runtime CXF configuration WITHOUT using Spring
Posted by Benson Margulies <bi...@gmail.com>.
Steve,
One of the virtues of Spring is exactly that you can put 'your toe in
the water'. The whole idea of the thing (well, the IoC part of the
thing) is that you write your code as if it wasn't there. Then you use
Spring to connect your pieces together. You \can/ make your code
Spring-aware, but for most cases you don't have to. Someone has to
write code to start the circus, but we did that for you.
cxf.xml is a spring bean configuration file. When you use the CXF
servlet and configure with this file (as opposed to the springless
configuration Dan discussed), the CXF servlet starts up Spring and
uses it to wire up all of the CXF components -- and also your service
implementation.
So, Spring is active. Adding the property placeholder to the cxf.xml,
and thus to the spring situation, does what you want without making
you one iota more Sprung than you were before.
--benson
On Thu, Dec 11, 2008 at 10:41 PM, Steve Cohen <sc...@javactivity.org> wrote:
> Thanks. This is intriguing. Of course this involves Spring, which, again,
> I'm NOT using -- or am I??? My application isn't consciously part of the
> Spring Framework - but then it does, of course need the Spring libraries for
> the CXF and cxf.xml is a Spring config file. So tell me - is it possible
> for me to put my toe in the Spring water without getting my whole body wet?
> I guess "all wet" would be defined as Spring in web.xml, etc. I can't
> afford the time to go that deep yet, but if this solves my problem, I could
> start edging in that direction and maybe (probably, I think) even like it.
> This approach to runtime environmental configuration is very much in the
> spirit of my home-grown system only more systematic.
>
> 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. Must
> I have a spring-config.xml to tell it where? And if so, what causes THAT to
> be loaded?
>
> I'm not snarking here. If I can make this work, I think I'll go with it.
> What is the minimum Spring footprint I need to get this going.
>
>
>
> Christian Schneider wrote:
>>
>> Hi Steve,
>>
>> there is a nice article that shows how to use the
>> PropertyPlaceHolderConfigurer.
>>
>>
>> http://icoloma.blogspot.com/2008/01/mock-your-spring-config-for-fun-and.html
>>
>> There is no list of passwords and locations. You simply have different
>> property files for your different environments. For example:
>>
>> Develop:
>> File config.properties
>> url=http://dev.server.com/service
>> username=client1
>> password=mydevpasswd
>>
>> Test:
>> File config.properties
>> url=http://test.anotherserver/service
>> username=client1
>> password=mytestpassword
>>
>> Ideally you manage to keep these files separate from your module (war in
>> your case). So you can deploy a new version by copying the war and the
>> config stays the same.
>> I guess you had a quite similar solution with your property files
>> already?!
>>
>> Greetings
>>
>> Christian
>>
>> Steve Cohen schrieb:
>>>
>>> Thanks, Christian.
>>>
>>> This certainly sounds like it could be the answer to my dilemma and I
>>> agree wholeheartedly with you that this is a normal scenario that needs to
>>> be supported.
>>> However, I don't fully understand what you are suggesting here.
>>> Something must be a selector (a key) into the list of locations and
>>> passwords and somehow this key needs to be passed to the object doing the
>>> resolution. Is there a fleshed out sample of this anywhere?
>>>
>>> Steve
>>>
>>
>>
>>
>
>
Re: Runtime CXF configuration WITHOUT using Spring
Posted by Steve Cohen <sc...@javactivity.org>.
Thanks. This is intriguing. Of course this involves Spring, which,
again, I'm NOT using -- or am I??? My application isn't consciously
part of the Spring Framework - but then it does, of course need the
Spring libraries for the CXF and cxf.xml is a Spring config file. So
tell me - is it possible for me to put my toe in the Spring water
without getting my whole body wet? I guess "all wet" would be defined
as Spring in web.xml, etc. I can't afford the time to go that deep yet,
but if this solves my problem, I could start edging in that direction
and maybe (probably, I think) even like it. This approach to runtime
environmental configuration is very much in the spirit of my home-grown
system only more systematic.
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.
Must I have a spring-config.xml to tell it where? And if so, what
causes THAT to be loaded?
I'm not snarking here. If I can make this work, I think I'll go with
it. What is the minimum Spring footprint I need to get this going.
Christian Schneider wrote:
> Hi Steve,
>
> there is a nice article that shows how to use the
> PropertyPlaceHolderConfigurer.
>
> http://icoloma.blogspot.com/2008/01/mock-your-spring-config-for-fun-and.html
>
>
> There is no list of passwords and locations. You simply have different
> property files for your different environments. For example:
>
> Develop:
> File config.properties
> url=http://dev.server.com/service
> username=client1
> password=mydevpasswd
>
> Test:
> File config.properties
> url=http://test.anotherserver/service
> username=client1
> password=mytestpassword
>
> Ideally you manage to keep these files separate from your module (war
> in your case). So you can deploy a new version by copying the war and
> the config stays the same.
> I guess you had a quite similar solution with your property files
> already?!
>
> Greetings
>
> Christian
>
> Steve Cohen schrieb:
>> Thanks, Christian.
>>
>> This certainly sounds like it could be the answer to my dilemma and I
>> agree wholeheartedly with you that this is a normal scenario that
>> needs to be supported.
>> However, I don't fully understand what you are suggesting here.
>> Something must be a selector (a key) into the list of locations and
>> passwords and somehow this key needs to be passed to the object doing
>> the resolution. Is there a fleshed out sample of this anywhere?
>>
>> Steve
>>
>
>
>
Re: Runtime CXF configuration WITHOUT using Spring
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Steve,
there is a nice article that shows how to use the
PropertyPlaceHolderConfigurer.
http://icoloma.blogspot.com/2008/01/mock-your-spring-config-for-fun-and.html
There is no list of passwords and locations. You simply have different
property files for your different environments. For example:
Develop:
File config.properties
url=http://dev.server.com/service
username=client1
password=mydevpasswd
Test:
File config.properties
url=http://test.anotherserver/service
username=client1
password=mytestpassword
Ideally you manage to keep these files separate from your module (war in
your case). So you can deploy a new version by copying the war and the
config stays the same.
I guess you had a quite similar solution with your property files already?!
Greetings
Christian
Steve Cohen schrieb:
> Thanks, Christian.
>
> This certainly sounds like it could be the answer to my dilemma and I
> agree wholeheartedly with you that this is a normal scenario that
> needs to be supported.
> However, I don't fully understand what you are suggesting here.
> Something must be a selector (a key) into the list of locations and
> passwords and somehow this key needs to be passed to the object doing
> the resolution. Is there a fleshed out sample of this anywhere?
>
> Steve
>
Re: Runtime CXF configuration WITHOUT using Spring
Posted by Steve Cohen <sc...@javactivity.org>.
Thanks, Christian.
This certainly sounds like it could be the answer to my dilemma and I
agree wholeheartedly with you that this is a normal scenario that needs
to be supported.
However, I don't fully understand what you are suggesting here.
Something must be a selector (a key) into the list of locations and
passwords and somehow this key needs to be passed to the object doing
the resolution. Is there a fleshed out sample of this anywhere?
Steve
Christian Schneider wrote:
> ...
>>
> Hi Steve,
>
> it is perfectly normal that configurations on develop and test systems
> are different. By using the spring PropertyPlaceHolderConfigurer in
> your cxf.xml you can externalise the username and password from this
> file.
>
> <bean id="propertyConfigurer"
>
> class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
>
> <property name="locations">
> <list>
> <value>classpath:config.properties</value>
> </list>
> </property>
> </bean>
>
> This allows you to use ${propertyname} in the file. For example:
>
> <http:conduit name="{http://some.com/service}port.http-conduit"
> <http://some.com/service%7Dport.http-conduit%22>;>
> <http:authorization>
> <sec:UserName>${username}</sec:UserName>
> <sec:Password>${password}</sec:Password>
> </http:authorization>
> </http:conduit>
>
> You can also replace the url of the service this way. So you can use
> one wsdl that contains a dummy url and replace the url for develop,
> test and production.
>
> I hope this will solve your problem.
>
> Greetings
>
> Christian
>> Please forgive me from using you guys as a punching bag.
>>
>>
>>
>
>
Re: Runtime CXF configuration WITHOUT using Spring
Posted by Christian Schneider <ch...@die-schneider.net>.
Steve Cohen schrieb:
> Please forgive my previous snark. It's been a long night.
>
> I overlooked possibility 4, that I'm an idiot. I simply wasn't
> getting all my other configuration parameters right, so I don't really
> know that the cxf.config.file definition mechanism wasn't working. I
> suspect it probably is.
>
> Your points are well-taken and in a perfect world I'd agree. My
> situation sucks, frankly. I work for a tiny underfunded backwater of
> a mega-corporation that won't spend and wants to exploit open-source
> without giving enough back in my opinion. The vendor is helping in
> his way, but then tells me stuff like "change your build process",
> "use Spring". My snark is better directed his way. The whole issue
> would go away if he would let me use the same credentials on his
> development and test systems.
>
Hi Steve,
it is perfectly normal that configurations on develop and test systems
are different. By using the spring PropertyPlaceHolderConfigurer in your
cxf.xml you can externalise the username and password from this file.
<bean id="propertyConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<list>
<value>classpath:config.properties</value>
</list>
</property>
</bean>
This allows you to use ${propertyname} in the file. For example:
<http:conduit name="{http://some.com/service}port.http-conduit" <http://some.com/service%7Dport.http-conduit%22>;>
<http:authorization>
<sec:UserName>${username}</sec:UserName>
<sec:Password>${password}</sec:Password>
</http:authorization>
</http:conduit>
You can also replace the url of the service this way. So you can use one wsdl that contains a dummy url and replace the url for develop, test and production.
I hope this will solve your problem.
Greetings
Christian
> Please forgive me from using you guys as a punching bag.
>
>
>
--
Christian Schneider
---
http://www.liquid-reality.de
Re: Runtime CXF configuration WITHOUT using Spring
Posted by Steve Cohen <sc...@javactivity.org>.
Please forgive my previous snark. It's been a long night.
I overlooked possibility 4, that I'm an idiot. I simply wasn't getting
all my other configuration parameters right, so I don't really know that
the cxf.config.file definition mechanism wasn't working. I suspect it
probably is.
Your points are well-taken and in a perfect world I'd agree. My
situation sucks, frankly. I work for a tiny underfunded backwater of a
mega-corporation that won't spend and wants to exploit open-source
without giving enough back in my opinion. The vendor is helping in his
way, but then tells me stuff like "change your build process", "use
Spring". My snark is better directed his way. The whole issue would go
away if he would let me use the same credentials on his development and
test systems.
Please forgive me from using you guys as a punching bag.
Benson Margulies wrote:
> Steve,
>
> I hope that my fellow volunteers and quasi-volunteers will pipe up on
> your specific technical issues presently. There are tests, for
> example, of the cxf.xml configuration mechanism in our test suite, so
> I have strong reason to believe that your problem is a configuration
> issue.
>
> At a higher level, my belief is that the situation is as follows.
> CXF's fundamental mission is to support the various complex standards.
> That requires a lot of components and a lot of moving parts. IoC in
> general, and Spring in particular, is an entirely appropriate
> mechanism for building something of this complexity. You can turn it
> into an insulting remark if you like, but that doesn't change the
> facts as I see them. Sure, we could invent our own IoC container, or
> use something other than Spring, but all we'd change would be the
> brand name.
>
> As with all open source platforms, CXF is what its contributors make
> it. As per the discussion that ensued from your previous posts, some
> contributors have some interest in adapting CXF to do very simple
> things very lightly, but pretty clearly it hasn't captured their
> attention.
>
> When I first started using XFire and then CXF, I ran into a series of
> issues not entirely dissimilar to yours. I had problems that were not
> well-aligned with the mainstream concerns of the contributors. I read
> the source. I figured things out. Now I'm stuck with maintaining
> pieces of it, but I have a nice, shiny, apache.org email address to go
> with it.
>
> This is pretty typical of the open source world in my experience, and
> so I'd advice you, however offensively, to take up source reading and
> debugging. In general, anyone proposing to use an open source platform
> for any task that isn't entirely cut-and-tried had better budget for
> such efforts. You can't stay on a schedule by depending on us
> volunteers to sort things out in a hurry.
>
> You say that CXF is on your plate due to a 'vendor'. This suggests to
> me that you and yours are paying them. So, why aren't they on the hook
> to solve these problem for you? On the other hand, as we all know,
> there is a commercialized variation on CXF. I personally do not work
> for Progress, but I have many, many, friends that do. If reading the
> source is not a cost-effective solution for you, perhaps buying
> professional assistance is.
>
> I can think of a few approaches to managing the credentials through
> the API instead of through the cxf.xml file, involving calling the
> Spring API to retrieve the relevant bean and stuffing the credentials
> into there from wherever you like.
>
> --benson
>
>
>
> On Thu, Dec 11, 2008 at 6:44 AM, Steve Cohen <sc...@javactivity.org> wrote:
>
>> I have been somewhat reluctantly dragged into using CXF (version 2.0.7) by
>> deadline pressure and vendor recommendation. I like many things about it
>> but there are issues. I've ranted about some of these issues before, but
>> don't want to dredge them up again. I believe it is overkill for my needs,
>> simply to create a SOAP client to access a vendor's web service.
>> Nonetheless, here I am.
>>
>> I am trying to deploy a CXF-based Web Service client into an architecture
>> that runs on Tomcat 6.0. We DO NOT at present use the Spring Framework,
>> although we may look at doing so as time permits, but time does not permit
>> such an exploration now. I have up to now used an architectural principle
>> that produces ONE war file that runs on all tiers (dev, test, production)
>> with differences between tiers resolved at runtime by properties files, etc.
>>
>> Our vendor has two systems, one for development and one for production.
>> Switching endpoints is managed by having CXF load different WSDLs. This is
>> suboptimal but manageable at runtime, by using properties files, and
>> needless to say, I don't want to be modifying the vendor's WSDL and
>> maintaining that over time.
>>
>> The backbreaker appears to be getting the CXF configuration to load. This
>> should be simple but it's turning into a nightmare. The vendor also has
>> given us different credentials for access to the different tiers of his
>> service and these can only be loaded via the CXF configuration, apparently.
>> I can't find any method that allows my application to select the proper CXF
>> config file at runtime. The only method by which my application is able to
>> successfully authenticate itself to vendor's service is by placing the
>> credentials a in file named "cxf.xml" (nothing else will do) residing on the
>> web app's classpath inside the war file. I have tried the suggestions at
>> the top of http://cwiki.apache.org/CXF20DOC/configuration.html, specifically
>>
>>
>>> CXF can discover XML configuration files which you have written. For both
>>> web service clients and servers, the default location that CXF will look for
>>> a configuration for is "/cxf.xml" on the class path. If you wish to override
>>> this location, you can specify a command line property:
>>> -Dcxf.config.file=some_other_config.xml. To use a url as the configuration
>>> location, specify as follows: -Dcxf.config.file.url=config_file_url.
>>>
>> and none of them work in my environment. Although my app can see the system
>> property "cxf.config.file" it does not affect how CXF finds its
>> configuration. My suspicions are either
>>
>> 1) The advice above does not work in CXF 2.0.7 which is what I am using. If
>> I can be assured that it fixed in a later release, I might be tempted to
>> make the switch.
>>
>> 2) This is a bug which does not work at all in any version of CXF.
>>
>> 3) this is another feature of CXF that depends on tighter integration with
>> Spring (I do have to include its jars but I'm not USING the framework).
>> This is becoming an annoying theme here - if this is the reason, you guys
>> might think about naming yourselves Spring XML Framework. It annoys me that
>> so much advice here assumes I'm using Spring. If that is a requirement, it
>> needs to be more strongly advertised in your materials. Hopefully this is
>> not the case.
>>
>> Can someone please enlighten me as to what is going on here? Switching
>> between different authentication credentials should not be this hard and I'm
>> willing to try almost anything at this point other than suggestions that I
>> migrate to Spring, change my build process, etc. While perhaps worthwhile,
>> I have no time for such things now.
>>
>>
>>
>
>
>
Re: Runtime CXF configuration WITHOUT using Spring
Posted by Benson Margulies <bi...@gmail.com>.
Steve,
I hope that my fellow volunteers and quasi-volunteers will pipe up on
your specific technical issues presently. There are tests, for
example, of the cxf.xml configuration mechanism in our test suite, so
I have strong reason to believe that your problem is a configuration
issue.
At a higher level, my belief is that the situation is as follows.
CXF's fundamental mission is to support the various complex standards.
That requires a lot of components and a lot of moving parts. IoC in
general, and Spring in particular, is an entirely appropriate
mechanism for building something of this complexity. You can turn it
into an insulting remark if you like, but that doesn't change the
facts as I see them. Sure, we could invent our own IoC container, or
use something other than Spring, but all we'd change would be the
brand name.
As with all open source platforms, CXF is what its contributors make
it. As per the discussion that ensued from your previous posts, some
contributors have some interest in adapting CXF to do very simple
things very lightly, but pretty clearly it hasn't captured their
attention.
When I first started using XFire and then CXF, I ran into a series of
issues not entirely dissimilar to yours. I had problems that were not
well-aligned with the mainstream concerns of the contributors. I read
the source. I figured things out. Now I'm stuck with maintaining
pieces of it, but I have a nice, shiny, apache.org email address to go
with it.
This is pretty typical of the open source world in my experience, and
so I'd advice you, however offensively, to take up source reading and
debugging. In general, anyone proposing to use an open source platform
for any task that isn't entirely cut-and-tried had better budget for
such efforts. You can't stay on a schedule by depending on us
volunteers to sort things out in a hurry.
You say that CXF is on your plate due to a 'vendor'. This suggests to
me that you and yours are paying them. So, why aren't they on the hook
to solve these problem for you? On the other hand, as we all know,
there is a commercialized variation on CXF. I personally do not work
for Progress, but I have many, many, friends that do. If reading the
source is not a cost-effective solution for you, perhaps buying
professional assistance is.
I can think of a few approaches to managing the credentials through
the API instead of through the cxf.xml file, involving calling the
Spring API to retrieve the relevant bean and stuffing the credentials
into there from wherever you like.
--benson
On Thu, Dec 11, 2008 at 6:44 AM, Steve Cohen <sc...@javactivity.org> wrote:
> I have been somewhat reluctantly dragged into using CXF (version 2.0.7) by
> deadline pressure and vendor recommendation. I like many things about it
> but there are issues. I've ranted about some of these issues before, but
> don't want to dredge them up again. I believe it is overkill for my needs,
> simply to create a SOAP client to access a vendor's web service.
> Nonetheless, here I am.
>
> I am trying to deploy a CXF-based Web Service client into an architecture
> that runs on Tomcat 6.0. We DO NOT at present use the Spring Framework,
> although we may look at doing so as time permits, but time does not permit
> such an exploration now. I have up to now used an architectural principle
> that produces ONE war file that runs on all tiers (dev, test, production)
> with differences between tiers resolved at runtime by properties files, etc.
>
> Our vendor has two systems, one for development and one for production.
> Switching endpoints is managed by having CXF load different WSDLs. This is
> suboptimal but manageable at runtime, by using properties files, and
> needless to say, I don't want to be modifying the vendor's WSDL and
> maintaining that over time.
>
> The backbreaker appears to be getting the CXF configuration to load. This
> should be simple but it's turning into a nightmare. The vendor also has
> given us different credentials for access to the different tiers of his
> service and these can only be loaded via the CXF configuration, apparently.
> I can't find any method that allows my application to select the proper CXF
> config file at runtime. The only method by which my application is able to
> successfully authenticate itself to vendor's service is by placing the
> credentials a in file named "cxf.xml" (nothing else will do) residing on the
> web app's classpath inside the war file. I have tried the suggestions at
> the top of http://cwiki.apache.org/CXF20DOC/configuration.html, specifically
>
>> CXF can discover XML configuration files which you have written. For both
>> web service clients and servers, the default location that CXF will look for
>> a configuration for is "/cxf.xml" on the class path. If you wish to override
>> this location, you can specify a command line property:
>> -Dcxf.config.file=some_other_config.xml. To use a url as the configuration
>> location, specify as follows: -Dcxf.config.file.url=config_file_url.
>
> and none of them work in my environment. Although my app can see the system
> property "cxf.config.file" it does not affect how CXF finds its
> configuration. My suspicions are either
>
> 1) The advice above does not work in CXF 2.0.7 which is what I am using. If
> I can be assured that it fixed in a later release, I might be tempted to
> make the switch.
>
> 2) This is a bug which does not work at all in any version of CXF.
>
> 3) this is another feature of CXF that depends on tighter integration with
> Spring (I do have to include its jars but I'm not USING the framework).
> This is becoming an annoying theme here - if this is the reason, you guys
> might think about naming yourselves Spring XML Framework. It annoys me that
> so much advice here assumes I'm using Spring. If that is a requirement, it
> needs to be more strongly advertised in your materials. Hopefully this is
> not the case.
>
> Can someone please enlighten me as to what is going on here? Switching
> between different authentication credentials should not be this hard and I'm
> willing to try almost anything at this point other than suggestions that I
> migrate to Spring, change my build process, etc. While perhaps worthwhile,
> I have no time for such things now.
>
>