I am trying to use the JAX-RPC 1.1 RI/SI that is part of JWSDP 1.3 to
generate code from the UDDI V3 WSDL/Schema descriptions. I have a
question/comment on the handling of a WSDL fault. I will try and describe
just enough of the WSDL and schemas to illustrate the problem, but I
apologize in advance for the length of this note. I am working on the next
release of the WSDL and schemas but I think this question/comment would
apply equally well to the published V3 WSDL and schemas.
Starting at the bottom, there is a schema defined in uddi_v3.xsd, with a
targetNamespace of urn:uddi-org:api_v3, which includes the following:
<xsd:element name="dispositionReport" type="uddi:dispositionReport"
final="restriction"/>
<xsd:complexType name="dispositionReport" final="restriction">
<xsd:sequence>
<xsd:element ref="uddi:result" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="truncated" type="uddi:truncated"
use="optional"/>
</xsd:complexType>
The namespace prefix "uddi" is associated with the targetNamespace of the
schema so the reference to "uddi:dispositionReport" is a reference to the
complexType in the same schema. Note that the element and the complexType
have the same name.
There is a WSDL file uddi_api_v3_portType.wsdl, with a targetNamespace of
urn:uddi-org:api_v3_portType, and this WSDL description includes the
following:
<message name="dispositionReportFaultMessage">
<part name="body" element="uddi:dispositionReport"/>
</message>
The schema within the types section of this WSDL description imports
uddi_v3.xsd, following the WS-I Basic Profile. The targetNamespace of the
schema is the same as the targetNamespace of the WSDL definitions element.
The uddi namespace prefix is associated with the targetNamespace of the
schema defined in uddi_v3.xsd.
A portType in this WSDL description includes the following operation:
<operation name="find_binding">
<input message="tns:find_bindingMessage"/>
<output message="tns:bindingDetailMessage"/>
<fault name="error" message="tns:dispositionReportFaultMessage"/>
</operation>
As you can see, the message is used as a fault message.
The SOAP/HTTP binding for this portType is contained in the file
uddi_api_v3_binding.wsdl and has the targetNamespace of
urn:uddi-org:api_v3_binding. This WSDL description imports the portType
WSDL and defines the SOAP/HTTP binding for the portType, including the
following for the operation in question:
<operation name="find_binding">
<soap:operation soapAction="find_binding"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
<fault name="error">
<soap:fault name="error" use="literal"/>
</fault>
</operation>
I created a WSDL service description, which is not part of the standard UDDI
WSDL, with a targetNamespace of urn:uddi-org:inquire_v3_service, and this
imports the binding and then creates a service with a port for the binding.
I then run wscompile against this WSDL service description with the
following options: -features:strict -gen:client -keep -verbose. The
config.xml I use contains a wsdl element with a location of the service WSDL
and a packageName of "org.uddi.v3.wsdl.service.inquire". I have added a
namespaceMappingRegistry which has two entries in it: 1) a mapping of the
namespace urn:uddi-org:api_v3_portType to the package
org.uddi.v3.wsdl.portType.api; 2) a mapping of the namespace
urn:uddi-org:api_v3 to the package org.uddi.v3.schema.api.
When I run wscompile, all of the code generated is in the
...\org\uddi\v3\wsdl\service\inquire directory, including a
DispositionReportFaultMessage.java file, which is the crux of the issue.
My reading of section 4.3.6 of the JAX-RPC 1.1 Specification is that the
name of the exception should be DispositionReport, not
DispositionReportFaultMessage, and I would expect it to be generated in the
org.uddi.v3.schema.api package
There is only one constructor for DispositionReportFaultMessage, which takes
a javax.xml.soap.SOAPElement named error as its only parameter, and there is
a single getter method, named getError which returns a
javax.xml.soap.SOAPElement.
Have I misunderstood the JAX-RPC specification, or is this a bug in the
RI/SI?
John Colgrave
IBM
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net