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:[EMAIL PROTECTED]]
Sent: Tuesday, January 07, 2003 2:14 PM
To: [EMAIL PROTECTED]
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" <[EMAIL PROTECTED]>
01/07/2003 02:03 PM
Please respond to axis-user
To: <[EMAIL PROTECTED]>
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:[EMAIL PROTECTED]]
> Sent: Tuesday, January 07, 2003 1:50 PM
> To: [EMAIL PROTECTED]
> 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/java/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
[EMAIL PROTECTED]
Web Services Development
IBM UK Laboratories, Hursley Park
(+44) 01962 818320, x248320, MP208.
"Jacques-Olivier Goussard" <[EMAIL PROTECTED]> on 07/01/2003 14:20:32
Please respond to [EMAIL PROTECTED]
To: <[EMAIL PROTECTED]>
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
