axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benazech Cédric <Cedric.Benaz...@atosorigin.com>
Subject RE: Java2WSDL
Date Fri, 19 Apr 2002 15:13:53 GMT
>>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