Perhaps my response was not clear -- I think you are asking why you
don't see the usual public static final statements?  The model for
building enumerations in Axis is one that is designed to be more robust
than the usual simple enumeration model. Hence, you see instantiations
of the class rather than the "constants" in the generated code.  You can
use the "constants" in the same way, though.  For instance, here is a
generated enumeration from my wsdl using my new generator -- the current
Axis will not have the _RAW and RAW generations since the list does
contain spaces:

public class DataFormatType implements java.io.Serializable {
    private java.lang.String _value_;
    private static java.util.HashMap _table_ = new java.util.HashMap();

    // Constructor
    protected DataFormatType(java.lang.String value) {
        _value_ = value;
        _table_.put(_value_,this);
    }

    public static final java.lang.String _value1 = "raw";
    public static final java.lang.String _value2 = "gzip";
    public static final java.lang.String _value3 = "delta then gzip";

    public static final java.lang.String _RAW = _value1;
    public static final java.lang.String _GZIP = _value2;
    public static final java.lang.String _DELTA_THEN_GZIP = _value3;

    public static final DataFormatType value1 = new
DataFormatType(_value1);
    public static final DataFormatType value2 = new
DataFormatType(_value2);
    public static final DataFormatType value3 = new
DataFormatType(_value3);

    public static final DataFormatType RAW = value1;
    public static final DataFormatType GZIP = value2;
    public static final DataFormatType DELTA_THEN_GZIP = value3;

    public java.lang.String getValue() { return _value_;}
    public static DataFormatType fromValue(java.lang.String value)
          throws java.lang.IllegalStateException {
        DataFormatType enum = (DataFormatType)
            _table_.get(value);
        if (enum==null) throw new java.lang.IllegalStateException();
        return enum;
    }
    public static DataFormatType fromString(java.lang.String value)
          throws java.lang.IllegalStateException {
        return fromValue(value);
    }
    public boolean equals(java.lang.Object obj) {return (obj == this);}
    public int hashCode() { return toString().hashCode();}
    public java.lang.String toString() { return _value_;}
    public java.lang.Object readResolve() throws
java.io.ObjectStreamException { return fromValue(_value_);}
}

I can then use DataFormatType.RAW exactly as one might with the simple
enumeration (same as if I used DataFormatType._value1 or
DataFormatType._RAW above).  

Hope this is clear?

Best,

Joe

-----Original Message-----
From: McDaniel, Joe 
Sent: Wednesday, December 10, 2003 1:04 PM
To: [EMAIL PROTECTED]
Subject: RE: Enumeration Question


Stuart,

I submitted a revised class for producing enumerations that will produce
more user-friendly enumerations (no VALUE1 stuff) and is still
compatible with the old code set. If you limit your enumerated list to
items without spaces, then you can get an enumeration that is usable. 

Best,

Joe

-----Original Message-----
From: Stuart Barlow [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, December 10, 2003 6:43 AM
To: [EMAIL PROTECTED]
Subject: Re: Enumeration Question


Apologies for continuing this old discussion but...

I see from the discussion that WSDL2Java is able to convert simple
enumerated types into Java static final values.

However when I run Java2WSDL in the first step of creating my webservice
the public final static fields do not get created in the WSDL. Is this
the expected behaviour?

If I want enumerated types available to my client do I need to manually
edit the WSDL after running the Java2WSDL tool?

Thanks,
Stuart.

McDaniel, Joe wrote:

> OK -- I found the "magic!"  Does not seem to be documented, but in one

> of the tests for Axis I found this:
> 
> <!-- The following test all of the valid enum basic types -->
>       <xsd:simpleType name="enumString">
>         <xsd:restriction base="xsd:string">
>           <xsd:enumeration value="Ho Ho Ho"/> <!-- Blanks should force
> value<1..n> names -->        
>           <xsd:enumeration value="He He He"/>                    
>           <xsd:enumeration value="Ha Ha Ha"/>                    
>         </xsd:restriction>
> 
> Ergo, if one does not have any spaces in any of the enumerated values,

> then it will automatically generate useful values.  IMHO, one should
> simply replace spaces with _ and generate HO_HO_HO instead of VALUE1.
> 
> Joe
> 
> -----Original Message-----
> From: McDaniel, Joe
> Sent: Thursday, November 20, 2003 10:05 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Enumeration Question
> 
> 
> Hi Albert,
> 
> OK -- that makes a bit of sense although the type-safe "feature" then
> means it is not compile-time "safe" since you cannot use the static 
> variables (unless you want to use the NotificationType._value1, ...). 
> What I see, in practice, is things like:
>  
>       
> nhq.setNotificationType(org.jtc.wo.NotificationType.fromString("data
> delivery"));
> 
> instead of something that can be checked at compile time such as:
> 
>       
> nhq.setNotificationType(org.jtc.wo.NotificationType.DATA_DELIVERY);
> 
> If the names were such as what I show instead of the _value1 pattern,
> then the enumerations would be much more useful at compile time.
> 
> Best,
> 
> Joe
> 
> -----Original Message-----
> From: Albert Lin [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 19, 2003 5:09 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Enumeration Question
> 
> 
> This is because wsdl2java generates "typesafe enums" for each 
> enumeration. Basically, rather than just creating a series of "static 
> final" constants, it creates objects for each enumeration, which has a

> major advantage of preventing you from assigning an invalid value to
an 
> enumeration.
> 
> A good description of typesafe enums is here:
> http://developer.java.sun.com/developer/Books/shiftintojava/page1.html
> 
> -- Albert
> 
> 
> On Wednesday, November 19, 2003, at 12:55  PM, McDaniel, Joe wrote:
> 
> 
>>Enumerations using wsdl2java get created (in my opinion) brain-dead.
>>Is there a reason for (or a work around) the way that wsdl2java 
>>creates the static final parameters with names like Color._value1, 
>>Color._value2, etc. rather than something that could be useful such as
> 
> 
>>Color.RED, Color.BLUE, etc.?
>>
>>Best,
>>
>>Joe McDaniel
>>
>>
> 
> 
> 

Reply via email to