> -----Original Message-----
> From: Roberto.Chinnici_at_Sun.COM [mailto:Roberto.Chinnici_at_Sun.COM]
> Sent: 07 November 2003 21:51
> To: users_at_jax-rpc.dev.java.net
> Subject: Re: wscompile and exceptions/faults
>
> 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
Roberto,
Thank you for your prompt response. I had not realized/expected that the
switch to SOAPElement would take priority over the original XML construct,
by which I mean I did not expect that switching to SOAPElement would result
in a simpleType of mapping being applied even when the original XML was a
complexType.
I should have mentioned that my goal is to tweak the UDDI schemas and WSDL
so that I can produce a JAX-RPC programming model for UDDI V3 without any
instances of SOAPElement. It seems I should ensure that I eliminate all
instances of SOAPElement before looking at the generated code too closely.
In this particular case, I removed the occurrences of the final attribute,
following your mention of it, and I now get a DispositionReport.java
generated where I expected, with the contents I expected (at first glance
anyway).
Thanks once again for your help.
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