Uploaded image for project: 'Application Server 3  4  5 and 6'
  1. Application Server 3 4 5 and 6
  2. JBAS-1377

bad path to included xsd gets built in WSDLFilePublisher

    XMLWordPrintable

Details

    Description

      SourceForge Submitter: mazzgolf .
      Problem when deploying a web service whose WSDL
      imports/includes other WSDL/schemas.

      See attached for a simple hello.war that illustrates this
      problem. To replicate, simply place the war file in the
      JBoss deploy directory and start.

      I don't think this has anything to do with platforms, but
      just in case - this is on JBoss 4.0, JDK 1.4.2, Windows
      XP SP1.

      Description:

      My web service WSDL imports another WSDL which in
      turn includes a schema (these are WSRF specification
      files).

      It looks like WSDLFilePublisher is not building the path
      correctly to that included schema. It's missing a "/" in
      one spot and has a double slash "//" in another spot.

      While debugging in WSDLFilePublisher, line 206 results in
      this as value for resourcePath:

      WEB-INF/wsdl//services/../spec/wsrfWS-
      ResourceProperties-1_1.xsd

      Note that there is a "/" missing between the last
      directory "wsrf" and the schema filename "WS-
      ResourceProperties-1_1.xsd". There is also a double
      slash "//" in there as well. The double-slash is probably
      OK and most file systems will parse it fine, however,
      obviously the missing slash is going to cause problems
      (which it does on my box).

      The value of this.expLocation was "WEB-INF/wsdl/" and
      the value of schemaLocation was "WS-
      ResourceProperties-1_1.xsd". baseURI had a value
      of "file:/C:/mazz/jboss/jboss-
      4.0.0/server/default/data/wsdl/jboss-
      wsdm.war/services/../spec/wsrf/WS-ResourceProperties-
      1_1.wsdl". this.di.shortName is "jboss-wsdm.war". index
      is 57. All of those values are correct.

      The WSDL includes the .xsd like this:

      <wsd:types><xsd:schema>
      <xsd:include schemaLocation="WS-ResourceProperties-
      1_1.xsd"/>
      ...

      The resulting exception is (which is actually thrown in
      line 210):

      16:13:24,774 ERROR [ServiceDeployer] Cannot startup
      webservice for: jboss-wsdm.war
      org.jboss.deployment.DeploymentException: Cannot
      publish wsdl to: C:\mazz\jboss\jboss-4.0.0
      \server\default\data\wsdl\jboss-
      wsdm.war\services\sensor.wsdl; - nested throwable:
      (java.lang.IllegalArgumentException: Cannot find schema
      import in
      deployment: WEB-INF/wsdl//services/../spec/wsrfWS-
      ResourceProperties-1_1.xsd)
      at
      org.jboss.webservice.WSDLFilePublisher.publishWsdlFile
      (WSDLFilePublisher.java:106)

      If, in my debugger, I fix the resourcePath evaluated on
      line 205 such that the path has the proper slashes, my
      web service deploys fine.

      In this example, its as if I made this fix on line 205 of
      WSDLFilePublisher.java

      from:

      resourcePath = resourcePath.substring(0,
      resourcePath.lastIndexOf("/"));

      to:

      resourcePath = resourcePath.substring(1,
      resourcePath.lastIndexOf("/") + 1);

      Obviously, it would be best if no assumptions were made
      about the location of "/" (that is to say, don't assume
      resourcePath has a leading "/" - I do above and hence
      the "1" in the first argument to substring). Probably
      would be better if we do something like this for the first
      parameter to that substring:

      resourcePath.charAt(0) == "/" ? 1 : 0

      Same holds true with that second argument. We should
      not do the "+1" if we know the schemaLocation is an
      absolute path. Otherwise, we'd introduce another
      double slash. So, perhaps, line 205 should be the
      following:

      resourcePath = resourcePath.substring
      (resourcePath.chatAt(0) == "/" ? 1 : 0,
      resourcePath.lastIndexOf("/") + (schemaLocation.charAt
      (0) == "/" ? 0 : 1));

      I'll leave it up to the commiter to decide the best course
      of action.

      John Mazz

      Attachments

        Activity

          People

            anil.saldhana Anil Saldanha (Inactive)
            tdiesler@redhat.com Thomas Diesler
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: