There isn't an architected way of doing this with the AXIS provider yet. I think there needs to be one and I am working on this, I'll let you know when something is available.
In the meantime if you know you are using the WSIF AXIS provider you can get the AXIS call object and then its TypeMapping registery by casting the WSIFPort to the AXIS provider port instance and using the public getCall method. For example: WSIFPort port = service.getPort(); WSIFPort_ApacheAxis axisPort = (WSIFPort_ApacheAxis) port; Call call = axisPort.getCall(); TypeMapping tm = call.getTypeMapping(); You can then use the register method on the TypeMapping to setup your own serializers. ...ant Anthony Elder [EMAIL PROTECTED] Web Services Development IBM UK Laboratories, Hursley Park (+44) 01962 818320, x248320, MP208. [EMAIL PROTECTED] on 10/01/2003 23:42:49 Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Re: [wsif] zip2geo sample questions Thanks, Anthony, for the excellent response. I upgraded to WSIF 2.0_RC and am now past my previous hurdle. Question though regarding dynamically registering a (de)serializer with WSIF, specifically for ApacheAxis. With Apache SOAP I was able to do it quite easily. With the Axis implementation I have not yet found a means of doing this. My attempts have been by using the TypeMappingRegistry from the WSIF level. Those do not seem to work. However, if I modify the code in WSIFOperation_ApacheAxis.java in the same area where the BeanSerializer is registered, I have success. I would rather not have to add code at that level if possible. Any recommendations will be appreciated. Thanks. Rhett "Anthony Elder" To: [EMAIL PROTECTED] <ant.elder@uk. cc: ibm.com> Subject: Re: [wsif] zip2geo sample questions 01/09/2003 04:31 AM Please respond to axis-user Here's a brief description of the way the WSIF AXIS provider currently works with document style operations. I'll try to write this up in more detail and put it in the doc directory shortly. The complexsoap sample using the zip2geo service is what as known as a wrapped document literal style service. This is the default way .Net does things. Its a little more complicated to explain than an rpc/encoded style operation so perhaps not the most simple example for WSIF to be using to demonstrate complex types. WSIF has a testcase for this which demonstrates all the possible ways of invoking the operation, so I'll use that to explain. Using the zipCode testcase as an example, see the testcase source at: http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-axis-wsif/java/test/docStyle/ZipCodeAxisTest.java and the WSDL it uses at: http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-axis-wsif/java/test/docStyle/wsifservice/zipCode.wsdl The above WSDL defines an operation called ShortZipCode: <operation name="ShortZipCode"> <input message="s0:ShortZipCodeSoapIn" /> <output message="s0:ShortZipCodeSoapOut" /> </operation> The input message looks like: <message name="ShortZipCodeSoapIn"> <part name="parameters" element="s0:ShortZipCode" /> </message> and ShortZipCode is defined in schema as: <s:element name="ShortZipCode"> <s:complexType> <s:sequence> <s:element minOccurs="1" maxOccurs="1" name="accessCode" nillable="true" type="s:string" /> <s:element minOccurs="1" maxOccurs="1" name="address" nillable ="true" type="s:string" /> <s:element minOccurs="1" maxOccurs="1" name="city" nillable ="true" type="s:string" /> <s:element minOccurs="1" maxOccurs="1" name="state" nillable ="true" type="s:string" /> </s:sequence> </s:complexType> </s:element> WSIF provides a number of ways of invoking this ShortZipCode operation: - with the input WSIFMessage having a single part named 'parameters' with a value being a complex type bean with getters/setters for the accessCode, address, city, and state Strings. - with the input WSIFMessage having 4 parts named 'accessCode', 'address', 'city', and 'state', each having a value of type String - with the input WSIFMessage having a single part named 'parameters' with a value being a DOM Element object The testcase referenced above has methods for each of these - doitDynWrapped, doitStubWrapped, doitDyn, doitStub, and doitMessaging, see the source for more details.. This is the way the current WSIF 2.0 AXIS provider code works, its quite different from the version 1.2 code and from the WSIF Apache SOAP provider doc style support. It has some known bugs and wrinkles yet to be resolved and is being actively worked on and tested over the next couple of weeks, after which it should be much more robust. Try it out and let me know of any bugs, issues, or features you'd like. ...ant Anthony Elder [EMAIL PROTECTED] Web Services Development IBM UK Laboratories, Hursley Park (+44) 01962 818320, x248320, MP208. [EMAIL PROTECTED] on 08/01/2003 22:17:31 Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Re: [wsif] zip2geo sample questions Hi Nirmal, Thanks for the quick response. I wanted to try a few things before I responded, and have now had time to do that. Essentially I am doing what you described with your code, except I am not using DOMs, but rather our code is structured so that all complex types get associated with a single dynamic serializer/deserializer. This works fine with rpc-style, and I don't see any reason it shouldn't work for doc-styles. Anyway, after I setObjectPart("parameters", value); and invoke the operation, WSIF returns the following error: Exception executing request: Error executing WSIF request: part zipcode, not found in input message ...and from the looks of the WSIF code, the convenience method actual changes the internal storage of a message to contain zipcode and licenseKey verus the original "parameters" part, thus demanding that those parts be set. I am not running the 2_0 RC code but the 1.2 code. Thanks. Rhett Nirmal Mukhi <[EMAIL PROTECTED] To: [EMAIL PROTECTED] .com> cc: Subject: Re: [wsif] zip2geo sample questions 01/08/2003 11:53 AM Please respond to axis-user Hi, Some bugs in my previous source code listing; here's the fixed version: // create the input, output and fault messages associated with this operation DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); DocumentBuilder db = dbf.newDocumentBuilder(); // at this point if you want to read the XML data from a file you could // do something like // Document doc = db.parse (new InputSource (new FileReader(..))); Document document = db.newDocument(); // create element according to what is reqd by service, as specified in WSDL Element topLevel = document.createElementNS("http://ws.cdyne.com ","GetLatLong"); topLevel.setAttribute("xmlns","http://ws.cdyne.com"); document.appendChild(topLevel); Element zip = document.createElement("zipcode"); Text zipValue = document.createTextNode(args[1]); zip.appendChild(zipValue); Element license = document.createElement("LicenseKey"); Text licenseValue = document.createTextNode(""); license.appendChild(licenseValue); topLevel.appendChild(zip); topLevel.appendChild(license); WSIFMessage input = operation.createInputMessage(); WSIFMessage output = operation.createOutputMessage(); WSIFMessage fault = operation.createFaultMessage(); // populate the input message input.setObjectPart("parameters",topLevel); // do the invocation if (operation.executeRequestResponseOperation(input, output, fault)) { // invocation succeeded, extract information from output // message Element retValue = (Element) output.getObjectPart ("parameters"); System.out.println("Got return value "+retValue); Thanks, Nirmal. [EMAIL PROTECTED] To: [EMAIL PROTECTED] 01/08/2003 11:47 AM cc: Please respond to axis-user Subject: [wsif] zip2geo sample questions In the WSDL for the Zip2Geo sample, the Message "GetLatLongSoapIn" contains a single part of "parameters" which references the element "GetLatLong" The sample code that invokes an operation using this message, the schema is unwrapped and two input parts are being set vs. the single part that is specified in the WSDL document. Also, this appears to be the case only when style="document" and use="literal". Does anyone know the reasoning behind this, i.e., the unwrapping of the element reference? Also, what happens is the element references a sufficiently complexType whereby the complexType is several layers deep and primitive types exist at each level? Is a input part then required for each of those primitives? Thanks much. Rhett DeWall Sybase Inc. 3665 Discovery Drive Boulder, CO 80303 303/413-4163