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.
