axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karen Lease (JIRA)" <>
Subject [jira] Commented: (AXIS-2412) [wsdl2java] if schema includes an element with type=xsd:anyType, unecessary classes are generated for all method wrappers
Date Thu, 23 Feb 2006 05:40:13 GMT
    [ ] 

Karen Lease commented on AXIS-2412:

Correction: the code which would stop this in org.apache.axis.wsdl.symbolTable.Utils (missing
in my description).

I poked around a bit in this area and found a few things:

1. the code  in getDerivedTypes() was commented out in version 261718, on 18jul2005 to fix
axis-2107. The problem there seemed to be that a wrapped-style wsdl defined an "operation"
type Help.  Normally no type class is generated for this in wrapped. But the Help element
was then referenced in the definition of a second method. This should have caused it to be
marked as referenced and generated, but didn't. 
The change to Utils caused the type to be generated because the schema contains at least one
reference to an "ANY" type, so then ALL types, including the anonymous one for Help are marked
as referenced. However, if the schema doesn't contain any references to an ANY type, this
change doesn't fix the bug.

2. I think the right place to fix axis-2107 is in the method setTypeReferences in the SymbolTable
class . Current code is:
// If this entry has a referenced type that isn't
            // the same as the nested type
            // AND the OnlyLiteral reference switch is on
            // THEN turn the OnlyLiteral reference switch off.
            // If only someone had put a comment here saying why we do this...
            if ((refType != null)
                    && !refType.equals(nestedType)
                    && nestedType.isOnlyLiteralReferenced()) {
This was added in version 256875 (cvs 1.77?) to fix axis-1105 (bugzilla 24141) on 25oct2003.
The problem described there is similar to the bug in axis-2107, except that the operation
type was defined using a type reference and not a nested anonymous type. The referenced type
was also used as a "parameter" to a different operation. This code (without the comments :-)
fixed that by marking the operation type as referenced so it would be generated. 

The check that  !refType.equals(nestedType) is to handle the case where the operation element
references its own type.
In the 2107 bug, the operation elements are defined using nested types not references to separate
type elements. In this case, refType is null. I would propose to change this to: 
     if (((refType == null)
                    || !refType.equals(nestedType))
                    && nestedType.isOnlyLiteralReferenced()) {
As far as I can tell from reading the code and testing various cases,  refType is always null
when we are looking for referenced types in an element with a nested type definition. I've
tested this on various cases and it always seems to do the right thing, but I haven't run
the full test suite with my two proposed changes.

> [wsdl2java] if schema includes an element with type=xsd:anyType, unecessary classes are
generated for all method wrappers
> -------------------------------------------------------------------------------------------------------------------------
>          Key: AXIS-2412
>          URL:
>      Project: Apache Axis
>         Type: Bug
>   Components: WSDL processing
>     Versions: 1.3
>  Environment: Linux (Mandrake 10) or Win 2000, java 1.4.1_01-b1
>     Reporter: Karen Lease
>  Attachments: test_anyType.wsdl
> I have a document/literal style wsdl with wrapped operations which references some data
types defined in the schema.
> After modifying one of my types to contain an xsd:any element, wsdl2java generated classes
for all of my anonymous operation
> and response wrapper elements. This doesn't happen if I use xsd:string for the element.
I think these types should not be
> generated.
> The code which would stop this is actually in in
the method getDerivedTypes() but 
> is commented out with this comment:
> // Currently we are unable to mark anonymous types correctly.
> // So, this filtering has to wait until a fix is made.
> If I uncomment this it fixes my problem.

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