Bug 780509 (SOA-2938)

Hi Noel,

can you please attach your JBDS project? I haven't managed to reproduce your issue. I created a simple HalloWorld process but it deploys and runs just fine.

Many thanks
Marek

Can you try a newer version of SOAP-UI? I used during my testing SOA-UI 3.0.1.

I am not sure about Noel's soapui version. 
With soapui-2.5 in my case, I've seen the same error as Noel.
Will try to upgrade the soapui now.

same error with soapui-3.6.1, :(

This is the example that I used in the bpel editor.

Attachment: Added: sayHello.tar

Got the exception too.

Looks like a jbossws-cxf issue. Using the 'say_hello' riftsaw quickstart, the WSDL being deployed with the JAX-WS service (that provides the WS interface to the BPEL service) has:

    <types>

        <schema attributeFormDefault="unqualified" elementFormDefault="qualified" 

                targetNamespace="http://www.jboss.org/bpel/examples" 

                xmlns="http://www.w3.org/2001/XMLSchema">


but the WSDL presented through the jbossws web console shows

  <types>
<schema attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="http://www.jboss.org/bpel/examples" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:plnk="http://docs.oasis-open.org/wsbpel/2.0/plnktype" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://www.jboss.org/bpel/examples">

Alessio - can you give your opinion on this issue. The default namespace on the schema element seems to be changed.

I've locally reproduced this error. From the ode code, there is org.apache.ode.bpel.compiler.wsdl.XMLSchemaTypeSerializer to copy the wsdl's namespace into schema element during bepl is compiled. I am not familiar with the ode code base , if there is some static thing  registered in the WSDLFactory's ExtensionRegsitry when ode starts up,  and it caused WSDL is parsed and wrote to the servlet response in the CXF with these wrong added namespaces later? Gary and Jeff, can you point me which ode or riftsaw classes should I look at to find out ? 
This could be the answer why jbossws native does not share this issue: in jbossws native stack , the customized WSDLFactory(JBossWSDLFactoryImpl) is used to parse and write the wsdl. CXF directly uses the WSDLFactory.newInstance() to fetch the WSDLFactory. This is the only difference between jbossws-cxf and jbossws-native to server the wsdl query request. 

I continue to investigate this issue . Let me know if you have thoughts about the current findings.  

No, don't know if ODE registers anything - we will check.

However if this is the case, then if you were to deploy any other JAXWS service, while ODE is installed, then it should cause the same error - is it possible for you to give this a try?

Actually I already tried to deploy a standalone JAXWS service which packaged in a war file(not dynamically generated by riftsaw), the generated wsdl file is correct. 
JBossWS CXF relies on  this method Transfomer.transform(DomSource, StreamResult) to output wsdl content, but the strange thing is javax.xml.transform.Transformer always generate wrong xmlns attribute( the wrong value: http://schemas.xmlsoap.org/wsdl/) of schema element in the whole bepl_say_hello example deploy process. And more interesting thing is when I debug the schema element before transform to stream result, the xmlns attribute is correct and it is "http://www.w3.org/2001/XMLSchema". This morning I already excluded the causes by transformer implements (xalan.jar) and jaxp implmentation(xerces.jar). Can you see any other jar file, settings or code in riftsaw or ode may cause this strang behavior ?     

Not that I know of, but will have a look.

First wanted to check whether it happens with ODE in Tomcat, and it doesn't - so its something about the ODE integration in jboss :(

There is a WSDLFactory implementation in runtime/engine module of riftsaw, which has some extensions related to handling the BPEL elements (partner links) that can be defined in the WSDL.

Thanks Jim for chasing this one down - it turned out to be the saxon transformer impl version (9.1.0.8). Version 9.2 looks fine.

Just a quick update, version 9.2 solves this particular problem but introduces some other issues - so started looking at whether it was really necessary to bundle the saxon impl, and unfortunately ODE is quite tightly coupled to it (i.e. variable resolve that returns Saxon specific classes to represent the values).

Next step (which won't be until next week probably) will be to investigate how easy it is to fix the 9.2 issues impacting the riftsaw integration tests.

If this is problematic, then the only other option may be to find a way to include a version of the Saxon artifacts without the META-INF/services information, so that jbossws uses the standard transformer implementation - and ODE still picks up Saxon as it explicitly instantiates the factories - not ideal though as it would mean having a separate slightly disabled version of the saxon artifacts in a different part of Nexus.

Link: Added: This issue is related to RIFTSAW-352

Fix was to change saxon jars in riftsaw.sar/lib with single saxonhe version 9.2 jar.

Release Notes Docs Status: Added: Documented as Resolved Issue
Writer: Added: dlesage
Release Notes Text: Added: https://issues.jboss.org/browse/SOA-2938

If the user  deployed a BPEL process on SOA-P 5.1 with the CXF stack configured, the WSDL would be invalid, leading to an java.lang.Exception: javax.wsdl.WSDLException.   To fix this problem, the Saxon JARs found in the riftsaw.sar/lib were replaced with single a saxon version 9.2 jar. As a result, users will no longer encounter this exception.

Verified in SOA 5.2 ER6, CXF, JBDS 4.1.1.

CXF generated WSDL documents can now be consumed be SOAPUI and other clients without problems.