My comments in <RJS>
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
"Peake, Chris"
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
om> cc:
Subject: RE: Java2WSDL
04/19/2002 10:28
AM
Please respond to
axis-dev
Another interesting point related to this subject.
The WSDL that gets generated has 'all' the public fields in the <sequence>
element of <types>.
Even if no get/set (i.e. bean structure) is present.
The generated clients for a complex type will then have get/sets created
for 'all' the fields in the <sequence> tag of the <types>.
So the bean description on client does not match the bean on server side
provided the web service bean had public fields 'without' get/set
structure.
<RJS> I agree that the client side bean class may have additional
getters/setters, but this should be okay. </RJS>
So if sending a complex type from the client to server, you will get an
exception since the 'BeanPropertyDescriptor' is based solely on
introspection of a bean that has get/set structure.
So the client sends all get/set type fields since getPD was used in
BeanSerializer and the complext type was generted with get/set for 'each'
field as described in WSDL. But on the server side, the same getPD on
BeanSerializer (called by BeanDeserializer) doesn't know about this 'extra'
get/set field because there is no get/set method for the field as there was
on the client.
<RJS> Yes this does seem to be a problem if the code is behaving the way
you say. The BeanDeserializer should set the public field directly if
there is no setter. </RJS>
It seems logical that if using something like 'ClassRep' instead of relying
on introspection for 'PropertyDescriptors' that we could send the public
fields of the type as well without relying on only fields that have get/set
structure. If WSDL is generating the <type> this way, it seems to make
sense that the public fields should 'not' be restricted. Even though the
bean spec points out how to access fields, I didn't think it restricted it.
Even if it did, if WSDL is going to behave as it does currently, which I
think is correct, then the serialization/derserialization maybe should
evolve too.
Also, I thought TypeDesc required a bean to have certain methods present
like "getTypeDesc" and "_Helper". If not there I thought typedesc was null
and basic introspection took place then.
I've just started looking at this, I could be way off or must be, because
that would not make sense.
chris
-----Original Message-----
From: Benazech Cédric [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 19, 2002 8:11 AM
To: '[EMAIL PROTECTED]'
Subject: RE: Java2WSDL
Just a comment :
I've seen that BeanSerializer uses *Rep AND *Desc ... AND
PropertyDescriptor AND BeanPropertyDescriptor.
I think it should be a good Idea to use only one of these classes that have
almost the same purpose.
Cédric
note : I'm not sure but I think that BeanPropertyDescriptor (that sort
fields) isn't usefull.
-----Message d'origine-----
De : R J Scheuerle Jr [mailto:[EMAIL PROTECTED]]
Envoyé : vendredi 19 avril 2002 14:49
À : [EMAIL PROTECTED]
Objet : Java2WSDL
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.
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.
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.
You win.
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
