John Colgrave wrote:
> 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?
Normally I'd agree with your analysis. It seems that the generated fault class
should be named after the dispositionReport complex type, per section 4.3.6 of
the specification.
But I see that there is a glitch, in that the dispositionReport complex type
lies outside the required envelope for JAX-RPC because it carries a
final="restriction" attribute information item. The portable mapping for this
type is then SOAPElement, at which point the clause in the sixth paragraph of
4.3.6 doesn't seem applicable any more.
I imagine that the RI then falls back on the seventh paragraph, treating the
fault in question as if it was of a non-complex type, hence the use of the
fault name as the basis to derive the exception name.
In my opinion this behavior is following the spirit of the spec, but I have
to admit that its correcteness is not apparent from section 4.3.6.
The alternative you propose is not too appealing, because it seems to be a mix
of the mappings for simple and complex types. (I'm referring to the use of the
fault name ("error") as the basis for deriving the name of the
SOAPElement-valued property carrying the fault information. This is a hint
that the rules for mapping complex types to exceptions break down in the
presence of a mapping of the whole type to SOAPElement.)
Thanks,
Roberto
--
Roberto Chinnici
Java Web Services
Sun Microsystems, Inc.
roberto.chinnici_at_sun.com
---------------------------------------------------------------------
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