axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adrian Price (JIRA)" <>
Subject [jira] Created: (AXIS-2464) Regression: WSDL2Java no longer maps enumeration restriction to JAX-RPC Enumeration patterm
Date Sun, 16 Apr 2006 16:24:29 GMT
Regression: WSDL2Java no longer maps enumeration restriction to JAX-RPC Enumeration patterm

         Key: AXIS-2464
     Project: Apache Axis
        Type: Bug

  Components: WSDL processing  
    Versions: 1.3    
 Environment: (Fedora Core 5 Linux)
    Reporter: Adrian Price

Axis 1.3 WSDL2Java no longer generates the correct code for simple types with enumeration
restrictions. Axis 1.1 (I don't know about 1.2), would emit a JAX-RPC enum pattern Java class
when it encountered an enumerated schema type. For example:

<simpleType name="DateSelector">
	<restriction base="xsd:string">
		<enumeration value="earliest-modified"/>
		<enumeration value="latest-modified"/>

would cause WSDL2Java to emit a class something like this:

public class DateSelector implements Serializable {
    public static final String _EARLIEST_MODIFIED = "earliest-modified";
    public static final String _LATEST_MODIFIED = "latest-modified";

    public static final DateSelector EARLIEST_MODIFIED =
        new DateSelector(_EARLIEST_MODIFIED);
    public static final DateSelector LATEST_MODIFIED =
        new DateSelector(_LATEST_MODIFIED);

    private static String[] _values = {

    private String _value;

    public static String[] getValues() {
        return _values;

    protected DateSelector(String value) {
        _value = value;

    public String getValue() {
        return _value;

    public static DateSelector fromValue(String value) {
        if (value == null)
            return null;

        if (value.equals(_EARLIEST_MODIFIED))
            return EARLIEST_MODIFIED;
        else if (value.equals(_LATEST_MODIFIED))
            return LATEST_MODIFIED;

        return null;

    public static DateSelector fromString(String value) {
        return fromValue(value);

In Axis 1.3 Java2WSDL still honours the JAX-RPC enum pattern and emits the correct WSDL (as
per the snippet at the top) but Axis 1.3 WSDL2Java incorrectly represents enumerated types
as ordinary strings, so we have lost the round-trip-ability that we had in 1.1 and possibly

The root cause seems to be some extensive refactorings that were performed on org.apache.axis.wsdl.toJava.JavaGeneratorFactory.javifyTypeEntryName(...).
Line 556 erroneously calls Type.setBaseType(true) in the following code snippet:

                    if (base.isBaseType()) {
                        // Case 2:
                        // <simpleType name="FooString">
                        //   <restriction base="foo:mySimpleStringType">
                        //   </restriction>
                        // </simpleType>
                        te.setBaseType(true);// <=== setting this to true prevents codegen
in Parser.generateTypes()

The logic above is overlooking the scenario where the simpleType contains a restriction. Anyhow,
in the case where Type contains an enumerated restriction setting baseType to true prevents
org.apache.axis.wsdl.gen.Parser.generateTypes() from calling Generator.generate() at line

            if ((type.getNode() != null)
                    && !Utils.isXsNode(type.getNode(), "attributeGroup")
                    && !Utils.isXsNode(type.getNode(), "group")
                    && type.isReferenced() && isType
                    && (type.getBaseType() == null)) { // <=== If baseType is true
this call returns the type name, not null, thus preventing code generation.
                Generator gen = genFactory.getGenerator(type, symbolTable);


It's entirely possible that the new code in JavaGeneratorFactory.javifyTypeEntryName() is
completely correct - I'm not familiar enough with the code to tell one way or the other. Perhaps
the correct solution is for the Parser.generateTypes() test which determines whether codegen
is required should take into account any enum-type restrictions imposed on the type.

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