Re: WSDL2Java Design Issue

[Martin Jericho]

Thanks Russell, I'm satisfied to know that it is an issue in the backs of people's minds.  I've now resigned myself to using pure data classes with SOAP, and transferring the data into my real classes.   Still I think the idea of separating the server side and client side generation is not so bad.  I think the fact that it is a combined operation at present may actually give people a false impression of their real relationship to each other.  SOAP is all about communication between heterogenous systems, and I totally agree that 99% of the time you would not want to share your original server side classes with the client.   Keep up the good work! Martin Jericho   ----- Original Message ----- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 11, 2002 11:23 PM Subject: Re: WSDL2Java Design Issue I won't disagree with you about SOME solution being good, here. But I doubt anyone has the time to address it right now. The best thing for you to do, so this issue isn't lost, is to open a bugzilla bug. 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?