axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Fassler (JIRA)" <>
Subject [jira] Commented: (AXIS-1720) Java2WSDL, repeated types auto-mapping to xsd:anyType causes bad definition in schema
Date Fri, 12 May 2006 15:46:09 GMT
    [ ] 

Jeff Fassler commented on AXIS-1720:

If you replace the code:
        if (!addToTypesList(qName) && !anonymous) {
            if (containingElement != null) {
                containingElement.setAttribute("type", getQNameString(qName));

            return true;

with the following:

String namespaceUri = qName.getNamespaceURI();
String lastSixCharsOfUri = namespaceUri.substring(namespaceUri.length() - 6, namespaceUri.length());
String lastFiveCharsOfUri = namespaceUri.substring(namespaceUri.length() - 5, namespaceUri.length());
         if (!addToTypesList(qName) && !anonymous && !lastSixCharsOfUri.equals(".javax")
&& !lastFiveCharsOfUri.equals(".java")) {
            if (containingElement != null) {
                containingElement.setAttribute("type", getQNameString(qName));
            return true;

then the issue for .java and .java type is solved, plus you are not left with the problem
of excess warnings being thrown.  I haven't tested vs doc/lit wsdl generation.  It is a big
kludgy, but it solves the problem.

> Java2WSDL, repeated types auto-mapping to xsd:anyType causes bad definition in schema
> -------------------------------------------------------------------------------------
>          Key: AXIS-1720
>          URL:
>      Project: Apache Axis
>         Type: Bug

>   Components: WSDL processing
>     Versions: 1.2RC2
>  Environment: J2SDK 1.4.2_06, Win2k
>     Reporter: Brett Randall
>  Attachments: AXIS-1720.patch.txt
> org.apache.axis.wsdl.fromJava.Types
> When running Java2WSDL on a class, if a type appears in the hierarchy contains more than
once, _and_ that type is one without a SerializerFactory mapped _and_ it is a class that fails
the isBeanCompatible test, Java2WSDL will create an invalid schema, by creating a namespace
and then referencing a non-existent type in that namespace.
> Test class: java.util.Locale.  Such a class fails the isBeanCompatible test, due to its
> If a single field of type Locale exists in a type hierarchy, all is fine: Types can't
find a serializer factory, so BeanSerializer defaults to XSD_ANYTYPE when types.writeType
returns null.
> If two fields of the same type that fail isBeanCompatible occur in a type hierarchy,
the first one is marked to be serialized as XSD_ANYTYPE, however the second one causes a problem,
and is marked with a namespace, however the type is never defined in that namespace.
> The cause is the too-early adding-to-namespace-list of the qname, which is occuring before
Types discovers that the type has no suitable factory.  The next pass through Types for the
same class type causes a false hit on the already-processed list, and a bad namespace is assigned
as a result.
> My fix for this is to move this block of code from Types.makeTypeElement():
>         // If we've already got this type (because it's a native type or
>         // because we've already written it), just add the type="" attribute
>         // (if appropriate) and return.
>         if (!addToTypesList(qName) && !anonymous) {
>         	if (containingElement != null) {
>                 containingElement.setAttribute("type", getQNameString(qName));
>             }
>             return true;
>         }
> ... down the method until after the point when a suitable SerializerFactory has been
located, or not in the case of a class like java.util.Locale, in which case the false namespace
mapping will not occur.
> If Java2WSDL is run against a class (or class hierarchy) with two fields of the same
such type, the resulting schema will include a reference to a namespace:type that will not
appear in the schema.
> Patch and very basic TestCase to follow (third method fails on 1.2RC2).  TestCase is
based on the current contract of Types.writeType(), which must return null if a schema could
not be created.
> Feel free to query me on this bug, as it is a little unusual.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message