|
Good point, but I still think the
amount of time and effort it would save developers is worth the trouble of
adding a flag and requiring the original class in the classpath. Maybe it
could be revisited once Axis has become more stable. What are the "risks"
you are thinking of?
Any comment on the second
suggestion? It doesn't suffer from the problems you
mentioned.
----- Original Message -----
Sent: Monday, June 10, 2002 11:37
PM
Subject: Re: WSDL2Java Design Issue
There is no sure way for WSDL2Java to know whether those
classes exist. If you're starting from WSDL they won't and WSDL2Java MUST
generate them.
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 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?
|
