Hi Lawrence,
big thanks for your explanation, it helped.
Once again thanks.
Pat
Lawrence Jones wrote:
> Hi Pat
>
> Hmmm. Let me describe it a bit and we can go from there.
>
> First of all XmlBeans is not a WSDL-based tool. It is a schema-based
> tool. Since a WSDL can contain a schema in its <types> section there is
> extra code in XmlBeans such that you can pass in a WSDL document to
> scomp (or the ant task). XmlBeans will then extract any <schema>
> elements from the <types> section and will then simply generate types
> based on those schema(s). But it does no further analysis of the WSDL
> and specifically takes no action based on anything outside of the
> <types> section.
>
> So when we are looking at your example below all that matters is the
> schema part - the <wsdl:operation> etc have no effect.
>
> Your schema defines a complex type with name "Exception" and
> targetNamespace "http://exc.pat";. I presume that somewhere else in your
> schema (not included below) there is an element called "Exception" which
> references that type?
>
> In that circumstance XmlBeans generates an ExceptionDocument interface
> (and underlying impl) to represent the element and an Exception
> interface (and underlying impl) to represent the complex type. This is
> the normal default behavior.
>
> You can override the names of the generated classes to be whatever you
> want (with the obvious exception that the generated interface for the
> element and the generated interface for the complex type must have
> different names) using a .xsdconfig file as discussed on a different
> thread -
> http://mail-archives.apache.org/mod_mbox/xmlbeans-user/200603.mbox/%3c99
> [EMAIL PROTECTED]
>
> When you actually have XML flowing around what you have is elements (not
> complex types). Elements have a name, complex types are like the
> template for everything that an element can have/contain but without the
> element name (of course they can have a complex type name but that
> doesn't appear in the XML instance document). So you really want to be,
> e.g., parsing incoming XML using the element class, not the complex type
> class and that's the class you should map your exception to.
>
> But lastly, assuming the above doesn't help you, you have only looked at
> the STS.documentTypes() method. This returns all the SchemaType objects
> for elements which can represent a document (ie it returns the same as
> STS.globalElements() except as SchemaType's instead of
> SchemaGlobalElement's). If instead you really do want the global types
> then I would call STS.globalTypes() instead.
>
> Cheers,
>
> Lawrence
>
>
>>-----Original Message-----
>>From: pat [mailto:[EMAIL PROTECTED]
>>Sent: Sunday, March 26, 2006 8:52 AM
>>To: [email protected]
>>Subject: generated faults java names
>>
>>Hi all,
>>
>>I'm trying to find out the place where the WSDL fault names are
>>converted to Java names (and the classes arround it).
>>
>>In company we want to use AXIS2 and XMLBeans. So, we have a WSDL and
>
> we
>
>>are able generate stub and beans, but there's a request to "hack" stub
>>generator to generate stub methods with faults as exceptions not as
>
> xml
>
>>beans.
>>
>>I've played with it a bit and found way to "hack" AXIS2 stub generator
>>to do that, but there's "missing" the support from the XMLBeans side.
>>
>>The fault type definition is something like this:
>><xsd:schema targetNamespace="http://exc.pat";
>>elementFormDefault="qualified" attributeFormDefault="qualified">
>><xsd:complexType name="Exception"/>
>></xsd:schema>
>></wsdl:types>
>>---the original package is pat.exc
>>
>>The method definition is:
>><wsdl:operation name="methodString">
>><wsdl:input message="tns:methodStringRequest"
>
> name="methodStringRequest"/>
>
>><wsdl:output message="tns:methodStringResponse"
>>name="methodStringResponse"/>
>><wsdl:fault message="tns:Exception" name="Exception"/>
>></wsdl:operation>
>>
>>When I run XMLBeans generator the final package structure generated
>
> is:
>
>>pat.exc.Exception - an interface
>>pat.exc.impl.ExceptionImpl - the interface implementation
>>pattest.ExceptionDocument - an interface
>>pattest.impl.ExceptionDocumentImpl - the interface implementation
>>
>>This is still acceptable. The pronlem starts in the SchemaTypeSystem,
>>because in the STS the bundle between QName({http://pattest}Exception)
>>and the real Java name contains only information about
>>pattest.ExceptionDocument, but I need to push the STS to return
>>pat.exc.Exception for the QName({http://pattest}Exception). Where is
>
> the
>
>>place to "hack" the STS - I've dabug a lot, but without luck :-\
>>
>>I'm using methods STS.documentTypes().getDocumentElementName() and
>>STS.documentTypes().getFullJavaName() for getting QName and Java name
>>
>>Can someone help me ???
>>
>>Thanks to all.
>>
>> Pat
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
