axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "R J Scheuerle Jr" <>
Subject Re: shared TypeMappings + new BeanSerializer behavior
Date Fri, 01 Mar 2002 16:43:32 GMT
See my comments <RJS>  below

Rich Scheuerle
XML & Web Services Development
512-838-5115  (IBM TL 678-5115)

                      Thomas Sandholm                                                    
                      <sandholm@mcs.anl        To:      
                      .gov>                    cc:                                    
                                               Subject:  shared TypeMappings + new BeanSerializer
                      03/01/2002 10:10                                                   
                      Please respond to                                                  

I got a new version from CVS yesterday, and I saw two new changes breaking
things for us that worked in the last version I checked out (Feb 6). I have

tried to track this to changes made to the code announced to this mailing
list without any success, so I'd appreciate if someone code shed some light

on why these changes were made, and possible workarounds.

Issue 1: shared TypeMappings
We have a lot of BeanMappings that must be shared among multiple services,
and they are hence put in the deployment scope of the server configuration,

and not within the local service element. In the new version the shared
TypeMappings are not picked up by the engine. The only mappings to be
picked up are the ones specified in the local service tag in the
deployment. This can be easily reproduced by modifying the deployment
descriptor of samples.userguide.example5 to move the BeanMapping out to the

global scope.

The functional tests are failing this morning and it appears that this
breakage occurred recently.  I agree this is a showstopper.  (Note
many of the committers are at an interop conference.)

Issue 2: BeanSerialization of java.lang.Object (xsd:anyType)
We have a lot of extensibility elements in our WSDL that are of type
xsd:anyType. When we send these across the wire on their own we see the
expected behavior, i.e. the client sends off a request with xsi:type set to

the actual type, and the server maps the type to the correct deserializer.
However, when we  send a complexType containing an xsd:anyType element
using the BeanSerializer, the client sets the type to xsd:anyType, and the
server is unable to deserialize the request (this happens even if a xsi:nil

is set) with the error: org.xml.sax.SAXException: !! No Deserializer for
class java.lang.Object.

Both of these issues are showstoppers at the moment, so I'd appreciate any
pointers, e.g. on how to modify/customize the BeanSerializer, and
TypeMapping registries to get it to behave like the old version (checked
out on Feb 6) when we didn't have any of these problems.

Could you send me an example bean class.  I can look into this.


Thomas Sandholm <>
The Globus Project(tm) <>
Distributed Systems Laboratory
Mathematics and Computer Science Division
Argonne National Laboratory

View raw message