Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cxf.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <015a01c95b88$e4c3b200$bb02050a@emea.progress.com>
From: "Sergey Beryozkin" <sergey.beryozkin@progress.com>
To: <users@cxf.apache.org>
References: <4940FD34.7050905@javactivity.org>
Subject: Re: Runtime CXF configuration WITHOUT using Spring
Date: Thu, 11 Dec 2008 12:06:25 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit

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.
>
>