From: Marko F. <mf...@bm...> - 2003-08-18 15:58:39
|
Hi folks, sorry for the long message, but I think I have to report this or I'll find me working around it again next time. After finally being able to go from 3.2.0beta to 3.2.1, I realized that a flaw I encountered earlier in the jboss.net module for xdoclet still exists. The flaw affects the ability to serialize bean type objects as return values into xml and breaks both the wsdl generator and the interoperability with gsoap (soap for cpp impl). The call itself works (on the jboss side) but the client (generated against a previously patched and working wsdl) cannot resolve the return type. Starting with the actual bean type class, there is nothing spectacular about it. There is only some attribute and the usual getter/setter stuff without any further xdoclet tags: ,-- SOAPProjectData.java -- | /** | * @jboss-net.xml-schema urn="SOAPProjectData" | */ | public class SOAPProjectData | extends AbstractData | { | ... | } `-------------------------- The stock CVS version of the jboss-net xdoclet module generates the following deployment descriptor: ,-- snippet from web-service.xml -- | <typeMapping | qname="SOAPProjectData" | type="java:de.sny.ejb.interfaces.SOAPProjectData" | serializer="org.apache.axis.encoding.ser.BeanSerializerFactory" | deserializer="org.apache.axis.encoding.ser.BeanDeserializerFactory" | encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> `---------------------------------- When a function returning an array of those objects is called, the call results in the following xml (you'll notice the "null" ns in the soapenc:arrayType value): ,-- snippet from server.log (containing the actually generated xml response) -- | <ns1:getProjectsResponse | soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" | xmlns:ns1="http://locahost:8088/jboss-net/services/Manager"> | <getProjectsReturn xsi:type="soapenc:Array" | soapenc:arrayType="null:SOAPProjectData[36]" | xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"> `----------------------------- Because of the incorrect xsi:type and the missing xmlns (see below), the client (which is compiled against a previously working version, because the wsdl cannot be generated, either) responds with: ,-- error output on client -- | SOAP FAULT: SOAP-ENV:Client | "Data type 'soapenc:Array' mismatch in element 'getProjectsReturn'" | Detail: http://localhost:8088/jboss-net/services/Manager `---------------------------- The error message when trying to get http://localhost:8088/jboss-net/services/Manager?wsdl is: ,-- snippet of the error message -- | Problem parsing '- WSDL Document -".: | The value of the attribute "xmlns:tns1" is invalid `---------------------------------- Previously (under 3.2.0beta) I therefore made a little patch to the xdoclet jboss-net module that still works. Basically, what it does is to add the prefix given as jboss-net parameter 'prefix' to the qname and add an xmlns:ns entry with the same value, too. It seems I cannot rememeber anymore how I came across that solution and given the fact that I am not at all comfortable with xml namespaces and stuff I thought I send it to the list and let you guys have a look. ,-- xdoclet/modules/jboss/net/resources/jboss-net_xml_tail.xdt -- | <!-- The following are typemappings for bean-type value-objects --> | | <XDtClass:forAllClasses type="java.io.Serializable"> | <XDtType:ifIsNotOfType type="javax.ejb.EntityBean"> | <XDtType:ifIsNotOfType type="javax.ejb.SessionBean"> | <XDtClass:ifHasClassTag tagName="jboss-net:xml-schema"> | <typeMapping | qname="<XDtConfig:configParameterValue paramName='prefix'/>:<XDtClass:classTagValue tagName='jboss-net:xml-schema' paramName='urn'/>" | xmlns:ns="<XDtConfig:configParameterValue paramName='prefix'/>" | type="java:<XDtClass:fullClassName/>" | serializer="org.apache.axis.encoding.ser.BeanSerializerFactory" | deserializer="org.apache.axis.encoding.ser.BeanDeserializerFactory" | encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> | </XDtClass:ifHasClassTag> | </XDtType:ifIsNotOfType> | </XDtType:ifIsNotOfType> | </XDtClass:forAllClasses> | | <!-- There follow merged custom web service descriptions --> | | <XDtMerge:merge file="web-service.xml"> | </XDtMerge:merge> | | </deployment> `-------------------------------------------- With the prefix param 'dsEjbWS' for the jboss-net task this obiously results in the new web-service.xml: ,-- snippet from web-service.xml (with the patch) -- | <typeMapping | qname="dsEjbWS:SOAPProjectData" | xmlns:ns="dsEjbWS" | type="java:de.sny.ejb.interfaces.SOAPProjectData" | serializer="org.apache.axis.encoding.ser.BeanSerializerFactory" | deserializer="org.apache.axis.encoding.ser.BeanDeserializerFactory" | encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> `---------------------------------- This results in a working wsdl output via .../services/Manager?wsdl and the proper generation of the xml response: ,-- working snippet from server.log (containing the actually generated xml response) -- | <ns1:getProjectsResponse | soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" | xmlns:ns1="http://locahost:8088/jboss-net/services/Manager"> | <getProjectsReturn xsi:type="soapenc:Array" | soapenc:arrayType="ns2:SOAPProjectData[36]" | xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" | xmlns:ns2="http://localhost:8088/jboss-net/services"> `----------------------------- OK, in case you managed to read up to here and have some comments and or an explanation what I did wrong in the first place (in case it is a feature rather than a bug or flaw), don't hesitate to contact me ;) just my 2 (EUR) cents, Marko -- www.bmx-chemnitz.de -==- 20 Zoll in Chemnitz mf...@bm... |