-
Bug
-
Resolution: Done
-
Major
-
None
-
None
JBoss fails to correctly implement the SOAP serialization semantics, which are spelled out in sections 5.4.1 "XML Mapping" and 5.4.2 "Java Serialization Semantics" of the JAX-RPC 1.1 specification.
In particular Section 5.4.1 states:
? Each read/write property (as identified by the java.beans.Introspector class) is mapped to an element in the xsd:complexType. The name attribute for the mapped
element is derived from the name of the property. The type attribute is mapped from the Java type of the property using the type mapping specified in the section 5.3,
?Java to XML Type Mapping?.
And Section 5.4.2 adds:
The default serialization semantics (termed SOAP serialization semantics) and on-wire
representation of a JAX-RPC value type are defined in terms of the XML mapping of a
JAX-RPC value type. Based on the standard XML mapping of a JAX-RPC value type
(as defined in the section 5.4.1, ?XML Mapping?), the default serialized state for a JAXRPC
value type includes only the XML mapping of the public fields and bean
properties.
However, when serializing a JavaBean, JBoss fails to distinguish between read-only properties (which must be excluded as per Section 5.4.1) and read/write properties (which must be included as per Section 5.4.1). Instead JBoss serializes both read-only and read/write properties.
In our environment (we are exposing existing session beans as service endpoints by appling the Java to XML/WSDL mapping ) this leads to:
1. JBoss producing SOAP envelopes that are inconsistent with their WSDL description;
2. Client of our application failing to deserialize SOAP envelopes produced by JBoss as they do not match the expected schema, which leads to data loss as clients fail to process application's replies when communication is done via service endpoints.
As there's no workaround for this issue and the problem leads to data loss, setting priority to critical.