Consuming an ASP.net web service using JAX-WS, obtaining "The specified type is abstract"

I am trying to create a quick sample Java client for a SOAP web service we have built with ASP.net.

The web service message schema makes use of many abstract classes with implementations of those, e.g. DeviceIdentifier (abstract), with SerialNumber and ProductNumber (these are hypothetical examples开发者_如何学JAVA to illustrate the question)

I used wsimport to create the client side proxy to consume the web service from my java code:

wsimport -extension -s c:\theservice -d c:\theservice -p theservice http://server/theservice?wsdl

I then assemble the message as follows:

GetDeviceReq request = new GetProductReq();
DeviceIdentifier id = new SerialNumber();
((SerialNumber)id).setUnitIdentifier(id);
GetDeviceResp response = service.GetDevice(request);

The code compiles perfectly and executes. However, I obtain a SOAPFaultException with the following message from the ASP.net web service:

The specified type is abstract: name='DeviceIdentifier', namespace='http://bogus', at <unitIdentifier xmlns='http://bogus'>.

I understand what the error message means, but I am running out of ideas as to why its happening in this case? I suspect it may have something to do with the way the wsimport tool generated the proxy code?

I solved my own problem!

I am using JDK 6, which includes JAX-WS 2.0. It looks like this version doesnt automatically decorate abstract classes with @XmlSeeAlso attributes. I manually modified the proxy code to include these attributes on the abstract classes. For the example give above:

The code generated by wsimport looks like this:

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "DeviceIdentifier")
public abstract class DeviceIdentifier {
}

I then added the @XmlSeeAlso:

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "DeviceIdentifier")
@XmlSeeAlso({SerialNumber.class, ProductNumber.class})
public abstract class DeviceIdentifier {
}

This is similar to the XmlInclude attribute in C#/.Net in System.Xml

It looks like this problem has been fixed in more recent versions of JAX-WS as per this article.