Bug 999570

OK, I've gone through this a bit; the reason for the issue here is basically that each CXF bus has a WSDLManager that caches WSDL definitions for each address. So, when building up for the second time a client against the same wsdl address, the wsdl definition is retrieved from the cache. Stopping the current bus (which forces a new one to be created at next client build time) or -better- creating a new bus just before building the second client ensures a fresh WSDLManager is in place.
The described WSDLManager related behaviour is by design, so I decided to give users an option for asking a given JAXWS service to be automatically built up in a new bus: https://issues.jboss.org/browse/JBWS-3699
As a consequence, the current issue could be solved by creating the JAXWS Service as follows:

Service service = Service.create(new URL(wsdlLocation), new QName(NAMESPACE, serviceName), new org.jboss.wsf.stack.cxf.client.UseNewBusFeature());

The test case is fixed. WSDLManager in the CXF Bus is still caching the wsdl and related information. The service has to be created using new bus

//To we need to avoid caching issues related to the WSDLManager in the CXF Bus.
Service service = Service.create(new URL(wsdlLocation), new QName(NAMESPACE, serviceName), new UseNewBusFeature())

verified for EAP version 6.2.0.ER5

Added draft Release Note text and marked for inclusion in the 6.2 Release Notes document.

I'm not exactly sure how the code supplied in comment 1 is to be utilized, so if anyone can provide info on how to actually use it (I suspect it's added to a file somewhere?) I'll add that to the release note (which currently suffers from not having that useful information).

Scott,
this ticket was originally created by QA because of a failing test that suggested we had a bug. It actually turned out that the observed behavior was the expected one, while the testcase needed to be fixed. For fixing the test, I created a new functionality for creating a JAXWS Service into a new Bus, created just for serving that Service (see comment 1). This prevents problems with cached values, like references to WSDL definitions that changed after the cache entry was saved.
The new functionality can be used in user code, if the user feels the wsdl he's creating a JAXWS Service against might have changed (which is not that common anyway for production environments).

Please let me comment on the proposed release notes:

"It was found that having each CXF bus cache WSDL definitions for each address could be problematic if the cached data is superceded in a later deployment scenario."

The reference to a "later deployment scenario" does not make a lot of sense. Why mentioning deployments? Deployments on which target / containers btw? The referenced wsdl might be hosted anywhere. It's just that we reproduced the scenario by deploying / undeploying proper test apps in our testsuite.

In any case, I'd rather write something like: "Users should be careful when building up JAXWS clients against previously used WSDL URLs. As a matter of fact, WSDL definitions are cached within the Apache CXF Bus that's used for serving the JAXWS client being created; a stale definition could be used if a different wsdl is now served at the specified URL and the same Bus is in use. To allow better control on cache usage, EAP 6.2 comes with a new functionality allowing creating a JAXWS client within a new Bus, whose WSDL definition cache would be empty. The new functionality is used as follows through the new "org.jboss.wsf.stack.cxf.client.UseNewBusFeature" JBossWS JAXWS Feature:

Service service = Service.create(new URL(wsdlLocation), new QName(...), new org.jboss.wsf.stack.cxf.client.UseNewBusFeature());
"

Thanks Alessio.

I've slightly modified the content you provided and have updated the Doc Text field and changed the Doc Type to 'Enhancement'.

Your timely input is greatly appreciated.