axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <gdani...@macromedia.com>
Subject RE: Java2WSDL
Date Fri, 19 Apr 2002 15:19:09 GMT

+1

> -----Original Message-----
> From: Benazech Cédric [mailto:Cedric.Benazech@atosorigin.com]
> Sent: Friday, April 19, 2002 11:14 AM
> To: 'axis-dev@xml.apache.org'
> Subject: RE: Java2WSDL
> 
> 
> >>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:scheu@us.ibm.com]
> Envoyé : vendredi 19 avril 2002 17:05
> À : axis-dev@xml.apache.org
> 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:
> "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>              
>                       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
> 
> 

Mime
View raw message