Web services tools enable you to define the following preferences:
A problem currently exists in that after adding a Handler in the Handler Configuration wizard, the wizard will generate a new skeletal Handler Java file into the primary source folder of your project unless a Handler Java file already exists at the same exact location and you have not selected "Do not overwrite loadable Java classes." The wizard does not check for existence of a Handler of the same fully qualified name elsewhere in the EAR. As a result, when you use the wizard to add a Handler that already exists somewhere else in the EAR, such as in a different source folder in your project or in a different module in the EAR, the wizard will write a new skeletal Handler, eclipsing your original Handler class. If this occurs, delete the skeletal Handler generated by the wizard.
When using the IBM SOAP run-time environment, the Web services wizard is now fully enabled to generate element-based mappings, in addition to any of the normal type-based mappings, if the "Enable element-based mapping" is selected.
If this preference is not enabled, which is the default, the Apache/IBM SOAP run-time environment may not interoperate with other vendors' Web service run-time environments that send messages whose elements do not have "xsi:type" properties. Web service run-time environments from other vendors follow various policies on the inclusion of xsi:type properties. Some always include them. Some never do. Some provide a configuration choice. Some omit xsi:types for certain types, like arrays.
The typical error produced by the IBM/Apache SOAP run-time environment is:
targetException=java.lang.IllegalArgumentException: No Deserializer found to deserialize a ':MyElement' using encoding style 'http://schemas.xmlsoap.org/soap/encoding/'. When enabled, element-based mappings are generated into:Element-based mappings are of the form:
<isd:map encodingStyle="encoding style" xmlns:x="some-namespace" qname="x:some-local-name" xml2JavaClassName="some-deserializer-class-name"/>An element-based mapping is generated for:
The WSAD Web services wizard follows the SOAP and XSD specifications to determine whether or not the element name in an element-based mapping should be qualified (that is, have a namespace) or unqualified.
The WSAD Web services wizard follows these rules for deciding between qualified and unqualified element names:
Some run-time environments are known to generate unqualified elements in SOAP messages despite a schema that specifies the use of qualified elements via the XSD schema's "elementFormDefault" attribute. In such cases, you may need to hand-edit a service's WSDL or XSD and change elementFormDefault to "unqualified".
An example of a non-namespace qualified element-based mapping is:
<isd:map encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:x="" qname="x:name" xml2JavaClassName="org.apache.soap.encoding.soapenc.StringDeserializer"/>
An example of a namespace qualified element-based mapping is:
<isd:map encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:x="http://www.ibm.com/" qname="x:name" xml2JavaClassName="org.apache.soap.encoding.soapenc.StringDeserializer"/>
Please note that only one element based mapping will be generated for a given element name. That is, if the schema uses the same element name more than once but with different types, only one of the elements will be selected, effectively at random, as the basis for one element-based mapping. The other identically-named elements of different types will fail to deserialize. The same is true if the schema uses the same name for an element and for a WSDL part.
<isd:map encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:x="" qname="x:some-name" xml2JavaClassName="some-serializer"/>
The XML editor may flag the following error:
The value of the attribute "xmlns:x" is invalid. Prefixed namespace bindings may not be empty.
This is harmless for the WebSphere Application Server V4. However, do not attempt to deploy this dds.xml to other server which uses Xerces 2.x (XML4J 4.x) or higher such as WebSphere Application Server V5. Otherwise, you will get similar Xerces parse error when the server loads the dds.xml file. You should regenerate dds.xml by going through the Web service scenario and selecting the right server type. This will generate the correct dds.xml for that server type.
Also, you would get similar Xerces parse error when attempting to deploy Web service from that ISD file. The workaround is to manually edit the file to the following format:
<isd:map encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" qname="some-name" xml2JavaClassName="some-serializer"/>
Parent topic: Web services overview
Related Concepts
Tools for Web services development
Related Tasks
Developing Web services