>>and I just made a change for 8191 so that only the public >>non-static fields are inspected.
What do you think about using the same introspection mechanisme for the exception and for beans ? Cédric -----Message d'origine----- De : R J Scheuerle Jr [mailto:[EMAIL PROTECTED]] Envoyé : vendredi 19 avril 2002 17:05 À : [EMAIL PROTECTED] Objet : RE: Java2WSDL Glen, Then change the factory stuff in WSDL2Java to use TypeDesc instead of ClassRep. Don't just disable the code and leave it laying around. Get rid of *Rep classes, the Factory classes etc. I am not a strong proponent of lumping all models together. A Java centric model is different than a Java/xml combined model. I think it is important to keep the Java2WSDL implementation separate from the runtime. I just hope over time the combined model does not develop too many warts. (I am not saying -1 here...its just a concern.) While you are at it, change the ServiceDesc to populate the FaultDesc by inspecting the bean property methods. Right now only the fields are inspected...and I just made a change for 8191 so that only the public non-static fields are inspected. You also may think about moving the FaultDesc stuff from ServiceDesc and putting it OperationDesc ? Rich Scheuerle XML & Web Services Development 512-838-5115 (IBM TL 678-5115) Glen Daniels <gdaniels@macrome To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> dia.com> cc: Subject: RE: Java2WSDL 04/19/2002 09:16 AM Please respond to axis-dev Hi Rich: First off, I'm sorry we haven't been communicating better throughout this process; I really didn't intend that this be a "win/lose" situation in any way.... I'll take the blame for some of this in that a detailed design document from me detailing what I wanted to do would have gone a long way towards smoothing these changes. > The purpose for the ClassRep and other *Rep classes in Java2WSDL was > to provide a model to represent the Java information. A user of the > emitter would then > have the capability to override the ClassRep to populate the Java > information in another > way. Ok. > But now this pluggability has been completely removed. > Java2WSDL now uses > the *Desc model exclusively. So in the attempt to move > forward, we have > lost some > more pluggability. Note that the *Rep model was useful for > representing > just > the Java information. The *Desc model is a combined Java/XML > model, so > they > are not the same thing. See next paragraph re: pluggability. Do you see another use for the Java-only information that isn't connected tightly to its XML-ness? My goal in this is to have one model for everything we deal with (services, types) to avoid duplicating functionality across packages as we were doing, and to allow us to make changes for this stuff in a single place. > Glen, if you don't want the ClassRep stuff anymore, please remove it > completely...and > all the pluggable stuff that I added since they are no longer > of any use. What I'd like to see is the *Desc model representing all the functionality we need, including the stuff that was in ClassRep. I don't think we've lost pluggability here: the "getTypeDescForClass()" method is the pluggability point for the new stuff, which currently looks for static data and helper classes. In the future, I'd like to see it also be able to read an XML file, but there's no reason you couldn't do anything else you wanted there either, including supplying a custom TypeDesc-getter. So whereas before you would override ClassRep to provide your own version of structured data, now you provide a TypeDesc with your own version of structured data. Do you see problems with this approach? ClassRep can/should go, after we make sure that the evolved *Desc system really does everything that ClassRep and friends were doing. > You win. Hopefully everybody wins, which is why we work on this stuff in the first place.... --Glen
