3 Replies Latest reply on Aug 6, 2007 4:32 PM by dlgrasse

    JBoss 4.0.x migration to 4.2.x

    dlgrasse

      I have been asked to move an existing web service application from the current JBoss 4.0.3SP1 AS to 4.2.1. My reading from the Wikis and FAQs lead me to believe that as long as certain specifics weren't being used, that the migration to JBossWS would be seamless (http://wiki.jboss.org/wiki/Wiki.jsp?page=JBWS404Compatibility). We had a few org.jboss.axis dependencies in our code (accessing the username/password from the rg.jboss.axis.MessageContext, etc), but I was able to use the JBossWS-1.2.1 jars and recompile fine after making a couple of changes to the code. So far, so good.

      I haven't been able to deploy though. I'm getting an error that seems to a jaxrpc-mapping issue. Specifically I'm seeing "The content of '{an xsd type}' is invalid. Element 'extension' is invalid, misplaced, or occurs too often.". The wsdl, webservice.xml, and jaxrpc-mapping files haved worked for years, and, except for a wsdl-port namespace issue in the webservice.xml file, haven't been changed.

      My own searches in this forum and Wiki and FAQ pages haven't turned up anything useful about this error.
      Could this be an issue exposed due to an XML parser change? Looking at the Xerces impl versions between the two AS', there is a minor version change.
      Or is there something fundamentally different that I'm not taking into account, and the specific error is a red herring? I was hoping to take the link above at its word and avoid any major changes (i.e. using annotations).

      I appreciate any pointers anyone could give. If it would be useful to see the jaxrpc-mapping, wsdl, or backing xsd types, I can certainly post relevant parts of the files here.

      dlgrasse

        • 1. Re: JBoss 4.0.x migration to 4.2.x
          juergen.zimmermann

          I updated my JBoss 4.2.1 with JBossWS 2.0 and things are working fine.

          • 2. Re: JBoss 4.0.x migration to 4.2.x
            dlgrasse

            Thanks for the idea. I removed the existing jbossws.sar dir in JBoss4.2.1, and installed JBoss2.0.0GA via the ant script, but got the same results.

            Troubleshooting this as if it were strictly an XML validation issue, I was able to remove the error mentioned in the first post. A second issue persisted though (org.jboss.ws.WSException: Cannot obtain java type mapping for {some wsdl schema type}). I was hoping it was caused by the schema error, but unfortunately it wasn't.

            Working through this problem I was able to resolve it by changing the contents of the jaxrpc-mapping file. Originally the java-xml-type-mapping's were mapping the wsdl element names to Java types. I had to change them to the schema types to get it to work. Here's an example of what I did:

            jaxrpc-mapping.xml

            <java-xml-type-mapping>
             <java-type>{mapped Java type}</java-type>
            
             <!--root-type-qname>impl:getReflistsRequest</root-type-qname>
             <qname-scope>element</qname-scope-->
            
             <root-type-qname>tns1:ReflistsInput</root-type-qname>
             <qname-scope>complexType</qname-scope>
            </java-xml-type-mapping>
            


            In my wsdl file is the following in the wsdl:types section:
            <wsdl:types>
             <schema xmlns='http://www.w3.org/2001/XMLSchema'
             targetNamespace='{impl namespace}'
             elementFormDefault='qualified'
             >
             <import namespace='{tns1 namespace}' schemaLocation='{schema file}'/>
            
             <element name='getReflistsRequest' type='tns1:ReflistsInput'/>
             </schema>
            </wsdl:types>
            


            Where I originally had the mapping to the wsdl element name, I had to change it to point to the underlying schema-defined XML type.

            Is this the expected behavior - a change from the earlier JBossWS implementation? Or is there a way to point to the wsdl names by namespace resolution?

            dlgrasse

            • 3. Re: JBoss 4.0.x migration to 4.2.x
              dlgrasse

              A quick followup on this...although I was able to get the webservice working with the afore-mentioned jaxrpc-mapping file changes, I am getting some undesirable behavior. Namely the nested tags now have to be resolved with a namespace. At least I'm suspecting that the jaxrpc-mapping changes have caused this need.

              As an example, the input XML now has to look like this:

              <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:xsd="http://www.w3.org/2001/XMLSchema"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              >
              <soapenv:Body>
              
               <getReflistsRequest xmlns="{wsdl types namespace}">
               <date xmlns='{schema types namespace}'>2005-08-17T18:13:42.417Z</date>
               <subset xmlns='{schema types namespace}'>RefLists</subset>
               </getReflistsRequest>
              
              </soapenv:Body>
              </soapenv:Envelope>


              whereas before it could look simply like this:
              <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:xsd="http://www.w3.org/2001/XMLSchema"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              >
              <soapenv:Body>
              
               <getReflistsRequest xmlns="{wsdl types namespace}">
               <date>2005-08-17T18:13:42.417Z</date>
               <subset>RefLists</subset>
               </getReflistsRequest>
              
              </soapenv:Body>
              </soapenv:Envelope>


              So it appears that since I can't define mappings Java<->WSDL elements, that as a result I have to resolve the schema elements in the payload. Any thoughts on this? Is there a way to provide jaxrpc-mapping java-xml-type-mapping's to WSDL elements? Or some other way to avoid the inner-tags being resolved? I was able to do this prior to before migrating to either JBossWS1.2.1 or JBossWS2.0.

              dlgrasse