JBoss fails to support SEI methods that feature JavaBeans whose properties' types are interfaces or abstract classes (this requires the use of the xsi:type attribute to indicate an instantiatable derived type).

For example given:

1. the following SEI:
public interface DemoServiceEndpoint extends java.rmi.Remote {
public Bean processBean(Bean p) java.rmi.RemoteException;
}
where the business method is implemented as
public Bean processBean(Bean p) {
if (p != null) System.out.println(p);
Bean returnValue = new Bean();
returnValue.setF(new Descr());
returnValue.getF().setDescription("Works as a nested return value!");
return returnValue;
}

2. the following Java classes:
public class Bean implements Comparable, Serializable {
private AbstractDescr f;
public AbstractDescr getF()

{ return f; }

public void setF(AbstractDescr value)

{ this.f = value; }

...
}
abstract public class AbstractDescr implements Comparable, Serializable {
private String description;
public String getDescription()

{ return description; }

public void setDescription(String value)

{ this.description = value; }

...
}

public class Descr extends AbstractDescr {
...
}

3. The following XML Schema mapping for AbstractDescr, Descr, and Bean:
<xsd:complexType name="AbstractDescr" abstract="true">
<xsd:all>
<xsd:element name="description" type="xsd:string"/>
</xsd:all>
</xsd:complexType>
<xsd:complexType name="Descr">
<xsd:complexContent>
<xsd:extension base="tns:AbstractDescr"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Bean">
<xsd:all>
<xsd:element name="f" type="tns:AbstractDescr" nillable="true"/>
</xsd:all>
</xsd:complexType>

4. The following java-xml-type-mapping entries for AbstractDescr and Descr:
<java-xml-type-mapping>
<java-type>rootpackage.application.business.common.AbstractDescr</java-type>
<root-type-qname xmlns:typeNS="http://common.business.application.rootpackage">typeNS:AbstractDescr</root-type-qname>
<qname-scope>complexType</qname-scope>
<variable-mapping>
<java-variable-name>description</java-variable-name>
<xml-element-name>description</xml-element-name>
</variable-mapping>
</java-xml-type-mapping>
<java-xml-type-mapping>
<java-type>rootpackage.application.business.common.Descr</java-type>
<root-type-qname xmlns:typeNS="http://common.business.application.rootpackage">typeNS:Descr</root-type-qname>
<qname-scope>complexType</qname-scope>
</java-xml-type-mapping>
<java-xml-type-mapping>
<java-type>rootpackage.application.business.common.Bean</java-type>
<root-type-qname xmlns:typeNS="http://common.business.application.rootpackage">typeNS:Bean</root-type-qname>
<qname-scope>complexType</qname-scope>
<variable-mapping>
<java-variable-name>f</java-variable-name>
<xml-element-name>f</xml-element-name>
</variable-mapping>
</java-xml-type-mapping>

JBoss generates (in response envelopes) soap:Body elements corresponding to the f element of Bean that don't contain the xsi:type attribute, which leads to:
1. The receiver not being able to deserialize the payload generated by JBoss resulting in spurious errors on the reveiver's side;
2. JBoss violating the XML Schema (that requires that for an element whose type definition is abstract, all instances of that element must use xsi:type to indicate a derived type that is not abstract).

Here's a return envelope that JBoss generated for this example:
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<ns1:processBeanResponse xmlns:ns1="http://logic.business.application.rootpackage">
<processBeanReturn>
<f> <!-- must contain xsi:type="tns:Descr" + a tns declaration... -->
<description>Works as a nested return value!</description>
</f>
</processBeanReturn>
</ns1:processBeanResponse>
</soapenv:Body>
</soapenv:Envelope>

I have a hunch that JBoss fails to generate xsi:type attributes for parameters too if one uses a J2EE client (that looks up a service interface in the JNDI tree) to access the corresponding service endpoint.

If required, I'll attach a sample application for this problem.