RE: TypeMappingRegistry getting "lost" during call

[Jana Poornavel]

Hi cameron,                   How do you load your Deserializing classes? Or let me put it this way,does your serializer Exist in your classpath ?   Regards, jana     Janarthanan Poornavel www.OrangeScape.com   From: Cameron F. Logan [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 09, 2004 10:13 PM To: [EMAIL PROTECTED] Subject: TypeMappingRegistry getting "lost" during call   I am developing an Axis-Castor based client application for a series of .NET web services using Axis v1.1 and Castor v0.9.5.3. I have built Axis using the Castor libraries, so the CastorDeserializer is available to me. I have used WSDL2Java to generate client proxies for the services. As per usual with the WSDL2Java generated proxy code, the type mapping information is loaded programmatically and I manually changed the BeanSerializer... entries to CastorSerializer entries.   Still, I have been receiving a "Deserializer not found" error upon execution of my client code and have painstakingly traced this down to a problem with either the MessageContext or the TypeMappingRegistry being effectively reset after the pivot. I can resolve the proper TypeMapping object for the each given response message successfully until the code hits the AxisClient class. Then the TypeMapping starts to resolve to null. I have tried included the client-config.wsdd file as an alternate means of providing type mapping information, but that yields the same error.   I know that this isn't a problem with the Axis/Castor integration because I am able to avoid the error and make successful calls to the web services by hard-coding the deserializer in the Call object to be the CastorDeserialzer.   Obviously, I do not want to hard code the deserializer this way, but so far it is the only thing that has seemed to work.   Can anyone shed light on why or how the TypeMapping information is cleared out half-way through the interaction with the web service? What could possibly be wrong? I can provide oodles of code if necessary, but thought I would start with the brief description of the problem. This is driving me crazy!   Thanks, Cameron ______________________________ Cameron F. Logan Envisa 281 Pleasant Street Framingham, MA 01701 tel:  508.405.1220 x112