OK, so here's the scenario: 1) In wsdl we define a binding to use literal encoding and rpc for an operation foo. 2) The foo operation has defined an input parameter called inParam of type xsd:anyType 3) Now we define an arbitrary type in XMLSchema called Bar, and generate a Bean for this type using WSDL2Java 4) We set up the deployment configuration to map our type BarNamespace:Bar to the BeanSerializer and BeanDeserializer 5) The client will then send something like the following across the wire when bar is passed as the inParam <SOAP-ENV:Body> <foo xmlns="http://my.test.org/foo-operation-namespace";> <inParam> <bar test="TestAttribute" /> </inParam> </foo> </SOAP-ENV:Body>
So what's the problem with this?-Well the problem with this is that the bar param has ended up in the operation namespace instead of the BarNamespace. This makes it impossible for the server side to fully determine the type that was actually passed across the wire. I tested this with code checked out from CVS earlier today. One difference from the code I played around with before (checked out on March 13th) is that I was able to deserialize the above message on the server side if I specified the service to use style="document" and the RPCProvider as the handler. The server basically gave my a DOM Element to play around with. With the code I tested that was checked out today, however, the server gives me an error like: org.xml.sax.SAXException: SimpleDeser cannot handle structured data! at org.apache.axis.encoding.ser.SimpleDeserializer.onStartChild(SimpleDeserializer.java:150) at org.apache.axis.encoding.DeserializationContextImpl.startElement(DeserializationContextImpl.java:824) at org.apache.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java:197) at org.apache.axis.message.MessageElement.publishToHandler(MessageElement.java:579) at org.apache.axis.message.RPCElement.deserialize(RPCElement.java:247) at org.apache.axis.message.RPCElement.getParams(RPCElement.java:271) at org.apache.axis.providers.java.RPCProvider.processMessage(RPCProvider.java:140) at org.apache.axis.providers.java.JavaProvider.invoke This is probably because the default serializer changed from ElementDeserializer to SimpleDeser or something along those lines. In any case I think the client proxy should pass in the namespace of the type it is serializing as the namespace of the parameter tag (inParam), in order for the server to do the correct mapping. Does this make more sense now? /Thomas At 03:15 PM 3/25/2002 -0500, Glen Daniels wrote: >Hi Thomas: > > > In our case the ideal solution would be to use literal > > encoding, and send > > the parameters with their tags qualified by their namespaces. > > Then on the > > server side you have access to the QName of the parameter > > type and can > > easily use the standard Axis typemapping to map it to a > > deserializer. This > > is however, currently not done by the proxies generated by > > WSDL2Java (i.e. > > the parameter tags are sent without namespace and xsi:type info) when > > literal encoding is used, which I reported on an earlier > > posting to this > > list, and hence it is impossible for the RPCProvider to > > determine what type > > is being sent across. > >Can you give me a concrete example of what you're talking about? I'm >pretty sure the parameters are being sent with the correct namespaces, but >you're right there are no xsi:types. We should still deal fine with this >using the literal support Tom and I have put in over the past few weeks. > >--G Thomas Sandholm <[EMAIL PROTECTED]> The Globus Project(tm) <http://www.globus.org> Ph: 630-252-1682, Fax: 630-252-1997 Argonne National Laboratory
