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 <[EMAIL PROTECTED]> 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. > >
