Great ! Thanks a lot for this.
I'll need this pretty fast, so I may end up patching AXIS
myself. Do you plan to fix this before releasing 2.0
(that is, if you fix it in WSIF) ?
Thanks again
Jacques-Olivier
> -----Original Message-----
> From: Anthony Elder [mailto:ant.elder@xxxxxxxxxx]
> Sent: Wednesday, January 08, 2003 9:53 AM
> To: axis-user@xxxxxxxxxxxxxx
> Subject: RE: wsif - complex type/java bean mapping
>
>
>
> Hi Jacques-Olivier, great find thanks,as you say WSIF should
> not to be AXIS
> dependant for the complex type mapping and this is a pretty serious
> problem.
>
> Whats going wrong is that the AXIS bean deserialiser
> (org.apache.axis.encoding.ser.BeanDeserializer) in the method
> onStartChild
> tries to find a BeanPropertyDescriptor for the XML element to be
> deserialised from the propertyMap. The propertyMap has been
> populated with
> all the properties of the bean by the
> org.apache.axis.utils.BeanUtils.getPropertyDescriptors which uses
> java.beans.Introspector to find the properties. Introspector
> determines the
> property names by manipulating the getter and setter method
> names which
> should follow standard Java naming conventions to get the
> actual property
> field name. So for example if there is a method called
> getFred(), then that
> should mean the bean has a field called fred. The AXIS
> BeanDeserializer
> then uses this name when trying to deserialise an XML element.
>
> The problem occurs when XML elements are defined with names
> starting with a
> capital letter. For example the complexsoap sample uses the
> Zip2Geo.wsdl
> which specifies the LatLongReturn complex type with an element called
> ServiceError. The Java class generated by WSDL2Java from this
> has a field
> called serviceError and methods isServiceError and
> setServiceError, so the
> BeanDeserialiser propertyMap populated by the Introspector will have a
> BeanPropertyDescriptor with the name serviceError with a
> lowercase 's'. But
> the incoming SOAP message needing deserialising will use the name
> ServiceError with an uppercase 'S' as specified in the WSDL.
>
> At line 217 in the BeanDeserializer class the following code
> looks up the
> property with the name from the XML Element which has the
> uppercase 1st
> character and will fail to find the BeanPropertyDescriptor:
>
> // look for a field by this name.
> propDesc = (BeanPropertyDescriptor)
> propertyMap.get(localName);
>
> Something like the following code added immediately after the
> above line
> fixes the problem:
>
> if (propDesc == null) {
> char[] ca = localName.toCharArray();
> ca[0] = Character.toLowerCase(ca[0]);
> String ln = ca.toString();
> propDesc = (BeanPropertyDescriptor)
> propertyMap.get(ln);
> }
>
> This only causes a problem with beans that don't have the
> AXIS specific
> methods which the BeanDeserialiser will use instead of the
> Introspector.
> The WSIF AddressBook sample names start with lowercase
> characters so work
> ok.
>
> Owen's going to post this to axis-dev to see what the AXIS
> people think
> about changing the BeanDeserialiser, otherwise we'll have to
> write our own
> WSIF specific one which we may need to do anyway depending on
> how long till
> the next AXIS release goes final. Watch axis-dev for progress.
>
> ...ant
>
> Anthony Elder
> ant.elder@xxxxxxxxxx
> Web Services Development
> IBM UK Laboratories, Hursley Park
> (+44) 01962 818320, x248320, MP208.
>
>
> "Jacques-Olivier Goussard" <jog@xxxxxxxxxx> on 07/01/2003 20:06:09
>
> Please respond to axis-user@xxxxxxxxxxxxxx
>
> To: <axis-user@xxxxxxxxxxxxxx>
> cc:
> Subject: RE: wsif - complex type/java bean mapping
>
>
>
> Thanks.
> Seems a pretty serious problem.
> One related question though. As per Ant remarks, I took a look to
> test/addressbook/AddressBookTest.java and indeed the Address
> class used as return type does not use the AXIS serialization
> stuff.
> How come this is working ? Is it something in the test setup
> (the build/samples path in front of the test/ path in the
> classpath for ex.) ?
> Jacques-Olivier
>
>
> -----Original Message-----
> From: Nirmal Mukhi [mailto:nmukhi@xxxxxxxxxx]
> Sent: Tuesday, January 07, 2003 2:14 PM
> To: axis-user@xxxxxxxxxxxxxx
> Subject: RE: wsif - complex type/java bean mapping
>
>
>
> Hello Jacques,
>
> You are right. We'll look into this problem and see what can
> be done. Keep
> monitoring this list for a response.
>
> Thanks,
> Nirmal.
>
>
> "Jacques-Olivier Goussard" <jog@xxxxxxxxxx>
> 01/07/2003 02:03 PM
> Please respond to axis-user
> To: <axis-user@xxxxxxxxxxxxxx>
> cc:
> Subject: RE: wsif - complex type/java bean mapping
>
>
>
> Thanks for quick response.
> I made a bit of progress on that problem:
>
> > Its a bit misleading if the samples contain the AXIS
> > serialization routines
> > as they are not used by WSIF. The AXIS WSDL2Java utility is used to
> Well, it does not seem obvious to me. Taking a look at
> wsif/providers/soap/apacheaxis/WSIFOperation_ApacheAxis.java,
> the method deserialiseResponseObject() will instanciate AXIS
> BeanDeserializerFactory based on the WSIFTypeMapping. In that case,
> AXIS seems to rely on an existing
> public TypeDesc getTypeDesc()
> (or alternatively a Deserializer getDeserializer())
> method implemented in the bean class itself.
> To make sure of this, just comment out the
> LatLongReturn#getTypeDesc and LatLongReturn#getDeserializer
> methods and run the complexsoap sample to experience the problem.
>
> > To map a complex type to a Java class you use the
> > org.apache.wsif.WSIFService class mapType method. For example:
> That's what the complexsoap example is doing.
>
> I would have expected WSIF not to be AXIS dependant for the complex
> type mapping, as it makes the client code dependant upon the chosen
> binding. From the code - but I'm really new to WSIF so there may be
> better ways - it seemed to me that the AXIS provider would have to
> generate the TypeDesc at runtime (i.e., doing WSDL2Java job) and
> use it to create the proper BeanDeserializers.
>
> Thanks
> Jacques-Olivier
>
> > -----Original Message-----
> > From: Anthony Elder [mailto:ant.elder@xxxxxxxxxx]
> > Sent: Tuesday, January 07, 2003 1:50 PM
> > To: axis-user@xxxxxxxxxxxxxx
> > Subject: Re: wsif - complex type/java bean mapping
> >
> >
> >
> > Its a bit misleading if the samples contain the AXIS
> > serialization routines
> > as they are not used by WSIF. The AXIS WSDL2Java utility is used to
> > generate the classes so they have the methods by default, but
> > they could be
> > deleted and everything should still work.
> >
> > To map a complex type to a Java class you use the
> > org.apache.wsif.WSIFService class mapType method. For example:
> >
> > service.mapType(
> > new javax.xml.namespace.QName(
> > "http://wsiftypes.addressbook/";,
> > "address"),
> > Class.forName("addressbook.wsiftypes.Address"));
> >
> > Or see the doitDyn method in this testcase for a complete example:
> > http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-axis-wsif/jav
> a/test/addressbook/AddressBookTest.java
> And the Address class it uses at:
> http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-axis-wsif/jav
a/test/addressbook/wsiftypes/Address.java
>
>
> When using the WSIFDynamicProxy for stub based invocation
> WSIF tries to
> find a class using the JAX-RPC rules for converting a QName to a Java
> class name. So in the above testcase the doit method uses
> stub invocation
> and does not need a mapType call as WSIF can find the
> addressbook.wsiftypes.Address class itself. If the class name
> doesn't match
> the QName you can still use mapType calls and stub invocation.
>
> ...ant
>
> Anthony Elder
> ant.elder@xxxxxxxxxx
> Web Services Development
> IBM UK Laboratories, Hursley Park
> (+44) 01962 818320, x248320, MP208.
>
>
> "Jacques-Olivier Goussard" <jog@xxxxxxxxxx> on 07/01/2003 14:20:32
>
> Please respond to axis-user@xxxxxxxxxxxxxx
>
> To: <axis-user@xxxxxxxxxxxxxx>
> cc:
> Subject: wsif - complex type/java bean mapping
>
>
>
> Hi
> I'm trying to build a generic webservice client that
> can handle complex types and is runtime configurable.
> Ideally, I wouldn't want users to have to provide a stub
> for their complex types.
> The WSIF documentation seems to indicate that any well
> behaved bean can be used to map complex types on the client
> side, but all the examples use WSDL2Java stubs, that contain
> AXIS deserialization routines. So
> 1 - Is there a way to map complex types to a simple bean (no
> AXIS getSerializer/getDesrializer routines)?
> 2 - If not, how can I register at runtime bean deserializers
> for AXIS from the WSIF interface ?
> Thanks
> Jacques-Olivier
>
>
>
>
|
