You could argue that, when generating server-side mappings, WSDL2Java should not generate them, but again, if you're starting from WSDL, you WANT it to generate them.
You could also argue that WSDL2Java should look to see whether they already exist. But that means that WSDL2Java must do one of two things:
1. to check for class existence, it needs the runtime CLASSPATH, whic is an unrealistic requirement.
2. to check for file existence, it needs to run in the root directory for that java file, which is also an unrealistic requirement.
A possible option is to provide a flag telling it NOT to generate the types, but that has it's own risks.
Russell Butek
[EMAIL PROTECTED]
Please respond to [EMAIL PROTECTED]
To: <[EMAIL PROTECTED]>
cc:
Subject: WSDL2Java Design Issue
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
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?
