1 Reply Latest reply on Apr 16, 2010 12:16 PM by wkubina

    Can JBossWS Metro handle XSDs contained in folders?

    wkubina

      This is a long post but any help is greatly, greatly appreciated!

       

      I've got a web service WSDL and set of XSDs that work in JBossWS Native but not in JBossWS Metro. The problem appears on the surface to be that Metro is not finding all the XSDs that should be referenced in the WSDL. Metro does find the XSD that is in the same folder as the WSDL, but it does not find XSDs that are nested deeper in folders (see folder structure below). I want to keep the other XSDs nested though because it is a standard (namely GML) that I am using and I don't want to modify the GML files.

       

      Here is a look at the applicable structure of my project.

        META-INF/wsdl/: This folder contains my WSDL and one XSD. The single XSD imports the GML XSDs that are contained in the folder listed in the next line.

        META-INF/wsdl/GML/3.1.1/: This folder contains GML 3.1.1 standard XSDs. These are the ones that are not being loaded properly.

       

      The reason I say the GML schema isn't being loaded properly is that they look to have an invalid reference inside my XSD. My WSDL references my XSD, and my XSD references the GML XSDs.

       

      So if I take a look at my deployed web service WSDL endpoint I see something like this (and the URL of the WSDL is http://localhost:8080/MyJar/MyWebService?wsdl)

      <code>

      <xs:import namespace="http://mynamespace.com/" schemaLocation="http://localhost:8080/MyJar/MyWebService?xsd=1" />

      </code>

       

      Although the import looks a tad different than JBossWS Native had it looking before it still links me to a valid XSD location, and it is in fact the correct XSD for that namespace (which is my single XSD that is in the same folder as the WSDL).

       

      However, when go to that XSD URL, the imports that are supposed to be for GML are incorrect. I anticipate that the import statement should have something similar to http://localhost:8080/MyJar/MyWebService?xsd=4 (or some other number) for the schemaLocation.

       

      But they actually look like this:

      <code>

      <import namespace="http://www.opengis.net/gml" schemaLocation="GML/3.1.1/base/gml.xsd"  />

      </code>

       

      So of course in a browser I can't get to that GML/... location to view gml.xsd. And I have also tried updating my relative path in my XSD to the GML schema by changing "GML/3.1.1/base/gml.xsd" to "./GML/3.1.1/base/gml.xsd". That doesn't work either and is an invalid URL and no client is able to parse the WSDL because the referenced schema are invalid.

       

      I should note too that if it isn't already obvious this is an EJB3 web service that gets packaged as a JAR (named MyJar.jar). I found a bug that says it was fixed and appears to deal with an issue similar or the same as the one I'm experiencing. The bug fix is documented here, and was made by Alessia, the web service lead: http://lists.jboss.org/pipermail/jbossws-commits/2008-October/007371.html.

       

      You might be wondering why I would switch to Metro is Native was working. Well, Native did not have the problem I'm describing in this post but it did seem to force web service clients to use JBossWS libraries to connect to a web service that has FastInfoset enabled (which I want to use). I didn't determine the true source of the cause, but from what I read and saw happening it appears as though the community version of Native has modified the FastInfoset standard encoding a bit so that other Java framework libraries that use FastInfoset (e.g. Metro 2.0, Axis2, etc.) cannot understand the FI information the JBoss server is returning. If that's incorrect please correct me!

       

      Thanks for reading all this and please help me if you know how to solve this problem! If you're a developer familiar with the code and want me to submit a bug report I can do that - just point me in the correct direction. I can also give more detailed information if it's needed.