During this work, one of our newly created services started to give us trouble. We could not create a SoapUI project for it. The WSDL URL looked fine, and at first glance all the generated XSDs looked ok (as I found out later they weren't). After a lot of debugging work I've finally tracked the issue down to the fact that this new service is using a JAXB generated object as an OUT parameter i.e. the return type.
To elaborate, we generated a client jar for our IHE XDS.b registry, this created all of our JAXB objects based on the IHE XSDs, since our service is a wrapper around this registry, we simply reused these classes.
Lets see what SoapUI was reporting...Some errors looked like this...
SoapUI Error Log
ERROR:error: src-resolve.a: Could not find type '[email protected]:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0'. Do you mean to refer to the type named [email protected]:oasis:names:tc:ebxml-regrep:xsd:rim:3.0?
Yet others looked like this...
SoapUI Error Log
ERROR:org.apache.xmlbeans.XmlException: Invalid QName value: Can't resolve prefix 'ns3'
org.apache.xmlbeans.XmlException: Invalid QName value: Can't resolve prefix 'ns3'
After looking through all of the generated XSDs from the deployed web service, it did in fact have missing and incorrectly used namespaces all over the place.
I decided to simply things, removed all other WebMethods and implemented something simple...
Java
@WebMethod(action = "testMethod")
public void test(
@WebParam(mode = WebParam.Mode.OUT,
name = "AdhocQueryResponse",
targetNamespace="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
)
Holder<AdhocQueryResponse> adhocQueryResponse
)
{
...
}
The SoapUI project still failed to create.
By accident I came across this blog post about JAXB namespaces, specifically the package-level metadata. That set off an alarm bell for me...I checked the client jar that contained all of our JAXB classes, and lo and behold, no package level metadata!
Why did this happen? Looking at the build system the clientgen task looked something like this...
ClientGen
<clientgen
...
packageName="${wls.xdsbregistry.package}"
...
The package name was being explicitly specified, forcing all class files into one location, but since the IHE XSDs use four separate namespaces, most of the namespace information was being lost!
The solution - remove the explicit package name definition. The result was a number of package-info.class files in the client jar with contents like this (decompiled)...
package-info.class
package oasis.names.tc.ebxml_regrep.xsd.query._3;
import javax.xml.bind.annotation.XmlNsForm;
import javax.xml.bind.annotation.XmlSchema;
@XmlSchema(namespace="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0", elementFormDefault=XmlNsForm.QUALIFIED)
abstract interface package-info
{
}
There you go, all the namespaces correctly defined.
After this change, a number of import statements in the service had to be updated, but once all of that was done and the service redeployed, we could create the SoapUI project without any issues and all the previous namespace problems were magically resolved.
-i
