Return-Path: Delivered-To: apmail-ws-axis-user-archive@www.apache.org Received: (qmail 92941 invoked from network); 10 Jun 2004 15:09:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 10 Jun 2004 15:09:32 -0000 Received: (qmail 98793 invoked by uid 500); 10 Jun 2004 15:09:18 -0000 Delivered-To: apmail-ws-axis-user-archive@ws.apache.org Received: (qmail 98731 invoked by uid 500); 10 Jun 2004 15:09:17 -0000 Mailing-List: contact axis-user-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-user@ws.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-user@ws.apache.org Received: (qmail 98721 invoked by uid 99); 10 Jun 2004 15:09:17 -0000 Received: from [216.239.56.241] (HELO mproxy.gmail.com) (216.239.56.241) by apache.org (qpsmtpd/0.27.1) with SMTP; Thu, 10 Jun 2004 08:09:17 -0700 Received: by mproxy.gmail.com with SMTP id r62so590147cwc for ; Thu, 10 Jun 2004 08:09:05 -0700 (PDT) Received: by 10.11.117.2 with SMTP id p2mr98916cwc; Thu, 10 Jun 2004 08:09:05 -0700 (PDT) Message-ID: <19e0530f04061008096fc6e91d@mail.gmail.com> Date: Thu, 10 Jun 2004 11:09:05 -0400 From: Davanum Srinivas Reply-To: dims@apache.org To: axis-user@ws.apache.org Subject: Re: TypeMappingRegistry getting "lost" during call In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N FYI, If you use http://axis-wsse.sourceforge.net/ you will not be able to interoperate with latest WSE 2.0 Final or latest JWSDP (released a few weeks back). You can use Apache WSS4J (http://ws.apache.org/ws-fx/wss4j/) if to support latest OASIS Web Services Security specifications. -- dims ----- Original Message ----- From: Cameron F. Logan Date: Thu, 10 Jun 2004 11:00:22 -0400 Subject: RE: TypeMappingRegistry getting "lost" during call To: axis-user@ws.apache.org Hi Everyone: I actually discovered the cause of my problem, and searching through this list's archives, I believe the same solution would apply to many others who have experienced similar issues. In the end, the solution was so simple that I'm almost embarrassed to post it here. The problem had nothing to do with Castor (de)serialization or the AxisClient class. The problem lie in the fact that I was using a ClientHandler to support WSSE [http://axis-wsse.sourceforge.net/]. Nevertheless, the ClientHandler itself was not the problem (in fact, I highly recommend it for simple Username/Password WSSE support). It was the fact that the "setClientHandlers" method was called that was the problem. This member of the org.apache.axis.client.Call class ends up calling its sibling member "setSOAPService" with a new SOAPService object. The SOAPService object is set as a private member of the Call object [with a variable name of "myService"]. This is all fine until the Call.invoke() method is executed by the SoapStub. It is within the logic of this method that "myService" is set to the MessageContext object. NOW THE PROBLEM BEGINS, for it is within the "setService" member of the MessageContext object that the MessageContext's encoding type is set to SOAP encoding. Since the service was using SOAP v1.1, the actual value of the encoding became: "http://schemas.xmlsoap.org/soap/encoding/". However, if we refer back to the SoapStub object that was generated by WSDL2Java, we see that the encoding under which the TypeMappingRegistry was created was "null". The TypeMappingRegistry that had been created is no longer visible to objects that are now attempting to retrieve TypeMappings for the SOAP1_1 encoding. Perhaps it should have been obvious to me that I would have to edit the encoding within the SoapStub object simply because I added a ClientHandler, but it was not. Regardless, the solution was to change the following line in the "createCall" member of the SoapStub from: _call.setEncodingStyle(null); to: _call.setEncodingStyle(org.apache.axis.soap.SOAPConstants.SOAP11_CONSTANTS.getEncodingURI()); AXIS v1.2beta code snippets shown to illustrate ================== SoapStub.createCall(): private org.apache.axis.client.Call createCall() throws java.rmi.RemoteException { try { org.apache.axis.client.Call _call = (org.apache.axis.client.Call) super.service.createCall(); if (super.maintainSessionSet) { _call.setMaintainSession(super.maintainSession); } if (super.cachedUsername != null) { _call.setUsername(super.cachedUsername); } if (super.cachedPassword != null) { _call.setPassword(super.cachedPassword); } if (super.cachedEndpoint != null) { _call.setTargetEndpointAddress(super.cachedEndpoint); } if (super.cachedTimeout != null) { _call.setTimeout(super.cachedTimeout); } if (super.cachedPortName != null) { _call.setPortName(super.cachedPortName); } java.util.Enumeration keys = super.cachedProperties.keys(); while (keys.hasMoreElements()) { java.lang.String key = (java.lang.String) keys.nextElement(); _call.setProperty(key, super.cachedProperties.get(key)); } // ***Added for WSSE support*** _call.setProperty(WsseClientHandler.PASSWORD_OPTION, WsseClientHandler.PASSWORD_CLEARTEXT); _call.setClientHandlers(new WsseClientHandler(), null); // All the type mapping information is registered // when the first call is made. // The type mapping information is actually registered in // the TypeMappingRegistry of the service, which // is the reason why registration is only needed for the first call. synchronized (this) { if (firstCall()) { // must set encoding style before registering serializers _call.setEncodingStyle(null); <=== Encoding under which TypeMappingRegistry gets indexed for (int i = 0; i < cachedSerFactories.size(); ++i) { java.lang.Class cls = (java.lang.Class) cachedSerClasses.get(i); javax.xml.namespace.QName qName = (javax.xml.namespace.QName) cachedSerQNames.get(i); java.lang.Class sf = (java.lang.Class) cachedSerFactories.get(i); java.lang.Class df = (java.lang.Class) cachedDeserFactories.get(i); _call.registerTypeMapping(cls, qName, sf, df, false); } } } return _call; } catch (java.lang.Throwable _t) { throw new org.apache.axis.AxisFault("Failure trying to get the Call object", _t); } } ================== Call.setClientHandlers(Handler, Handler: public void setClientHandlers(Handler reqHandler, Handler respHandler) { // Create a SOAPService which will be used as the client-side service // handler. setSOAPService(new SOAPService(reqHandler, null, respHandler)); <=== new SOAPService } ================== Call.setSOAPService(SOAPService): public void setSOAPService(SOAPService service) { myService = service; <=== myService gets set in the Call object if (service != null) { // Set the service so that it defers missing property gets to the // Call. So when client-side Handlers get at the MessageContext, // the property scoping will be MC -> SOAPService -> Call -> Engine // THE ORDER OF THESE TWO CALLS IS IMPORTANT, since setting the // engine on a service will set the property parent for the service service.setEngine(this.service.getAxisClient()); service.setPropertyParent(myProperties); } } ================== Call.invoke(): // Determine client target service if (myService != null) { <=== myService is not null; it was automatically set when setClientHandlers was called // If we have a SOAPService kicking around, use that directly msgContext.setService(myService); <===SOAPService set in MessageContext } else { if (portName != null) { // No explicit service. If we have a target service name, ================== MessageContext.setService(SOAPService): public void setService(SOAPService sh) throws AxisFault { log.debug("MessageContext: setServiceHandler("+sh+")"); serviceHandler = sh; if (sh != null) { targetService = sh.getName(); SOAPService service = sh; TypeMappingRegistry tmr = service.getTypeMappingRegistry(); setTypeMappingRegistry(tmr); // styles are not "soap version aware" so compensate... setEncodingStyle(service.getUse().getEncoding()); <=== Encoding style updated // This MessageContext should now defer properties it can't find // to the Service's options. bag.setParent(sh.getOptions()); // Note that we need (or don't need) high-fidelity SAX recording // of deserialized messages according to the setting on the // new service. highFidelity = service.needsHighFidelityRecording(); service.getInitializedServiceDesc(this); } } ================== -----Original Message----- From: Jana Poornavel [mailto:jpoornavel@orangescape.com] Sent: Thursday, June 10, 2004 12:59 AM To: axis-user@ws.apache.org Subject: RE: TypeMappingRegistry getting "lost" during call 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:cameron.logan@envisa.com] Sent: Wednesday, June 09, 2004 10:13 PM To: axis-user@ws.apache.org 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 -- Davanum Srinivas - http://webservices.apache.org/~dims/