Igor Kromin |   Consultant. Coder. Blogger. Tinkerer. Gamer.

I've been working on moving all of our services at work away from WSDL first and towards the JWS file approach. I think that is a much cleaner way of going about writing web services, it certainly is a lot quicker. I've even written a post previously that shows an example build system that uses the JWSC weblogic task to build JWS file base services.

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...
@WebMethod(action = "testMethod")
public void test(
@WebParam(mode = WebParam.Mode.OUT,
name = "AdhocQueryResponse",
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...

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


Hope you found this post useful...

...so please read on! I love writing articles that provide beneficial information, tips and examples to my readers. All information on my blog is provided free of charge and I encourage you to share it as you wish. There is a small favour I ask in return however - engage in comments below, provide feedback, and if you see mistakes let me know.

If you want to show additional support and help me pay for web hosting and domain name registration, donations, no matter how small, are always welcome!

Use of any information contained in this blog post/article is subject to this disclaimer.
comments powered by Disqus
Other posts you may like...