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.


A quick disclaimer...

Although I put in a great effort into researching all the topics I cover, mistakes can happen. Use of any information from my blog posts should be at own risk and I do not hold any liability towards any information misuse or damages caused by following any of my posts.

All content and opinions expressed on this Blog are my own and do not represent the opinions of my employer (Oracle). Use of any information contained in this blog post/article is subject to this disclaimer.
Hi! You can search my blog here ⤵
NOTE: (2022) This Blog is no longer maintained and I will not be answering any emails or comments.

I am now focusing on Atari Gamer.