The risks I see with a flag aren't terribly critical, but they have to be considered:
- if it says 'generate all types, yes or no' then you'd better be sure you really DO want to turn off generation of ALL types. What about imported types? So this probably is the wrong sort of flag.
- if you can pick and choose which types to generate, then the chance for user error is great. The more you require folks to type, the more likely there will be a typo, or an omission.
The idea of custom serializers for this scenario has been bandied about, but the division of client-side and server-side will be that much greater. Right now you can generate client-side and server-side together. But the custom serializers will probably ONLY be needed on the server side (though not exclusively - you MIGHT provide your pre-existing classes to clients, but then you might not). You'd have to be more cautious about how you use WSDL2Java. You'll have to run it once for server-side bindings. Then a second time, in a different directory, with a different classpath, for the client-side bindings.
It's a thorny issue, and it IS being thought about, but it's not high on anybody's list at the moment.
Russell Butek
[EMAIL PROTECTED]
Please respond to [EMAIL PROTECTED]
To: <[EMAIL PROTECTED]>
cc:
Subject: Re: WSDL2Java Design Issue
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 -----
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
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?
