WSDL2Java Design Issue

[Martin Jericho <ma...@jabcreative.com>]

Can someone please tell me why WSDL2Java creates new classes for any data
sent via RPC rather than using the original classes?

For example, if I have a bean called MyBean which contains a property called
MyProperty and some other public methods as follows:

public class MyBean {
    protected String myProperty;

    public MyBean(String myProperty) throws Exception {
        setMyProperty(myProperty);
    }

    public void setMyProperty(String myProperty) throws Exception {
        if (myProperty==null) throw new Exception("Can't set null
property");
        this.myProperty=myProperty;
    }
    public String getMyProperty() {
        return myProperty;
    }

    public String getUpperCaseMyProperty() {
        return myProperty.toUpperCase();
    }
}

WSDL2Java will create a new MyBean class, which overwrites my setMyProperty
and getMyProperty methods, makes the myProperty field private, and doesn't
have my constructor or getUpperCaseMyProperty method.  In other words, it
creates a new class which is a pure data representation of the original
class but removes all of its functionality.

To integrate this class into my existing code, I have to have a new
constructor which takes the generated MyBean as a parameter, and reconstruct
a real MyBean object from it.  I also have to write a method in the real
MyBean that will return an object of the generated class containing the same
data.

A far better solution would be to simply perform the serialization and
deserialization from a generated subclass.  This would mean that any fields
which must be serialized would have to be declared protected rather than
private, and the class would have to contain a no-argument constructor, but
that is still preferable to the current situation.  The interface to the
service could then use all the original classes and provide a seamless
integration.

An alternative to this would be if two classes are generated from the
original, one being a base class and another extending it.  The base class
implements the equals, hashCode, and serialization stuff as per normal, but
the subclass is simply an empty extention of it.  The subclass can then be
modified by the developer to override or implement any additional methods.
This is the way things are done in the jakarta Torque implementation, and
although it doesn't fit quite as nicely into this paradigm it is still an
improvement.  The only problem with it is that you can't have your bean
extending any other class.  To implement this in Axis would require only
very minimal changes.

Any comments?  Should I be directing this at the developer's mailing list
instead?

Specifying Data Constraints

[Martin Jericho <ma...@jabcreative.com>]

Is there any formal way of specifying which RPC method arguments are
optional/mandatory in the WSDL generated by Java2WSDL?  Is there any way to
have comments or method descriptions appear in it?
Thanks for any help