jax-ws
  1. jax-ws
  2. JAX_WS-857

jax-ws-catalog.xml not resolving schemaLocation in Metro 1.5

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Works as designed
    • Affects Version/s: 2.1.7
    • Fix Version/s: 2.2.6
    • Component/s: runtime
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

      Description

      I have added a jax-ws-catalog.xml to my .war file in order to resolve the
      schemaLocation locally instead of remotely in <xsd:import ..>. I've followed
      the example at

      https://jax-
      ws.dev.java.net/guide/Developing_client_application_with_locally_packaged_WSDL.h
      tml

      When I deploy the .war and use soapUI to validate the web service it gets stuck
      trying to access the schemaLocation
      http://somehost:8080/CMDB/schemas/common/1.0/CMDBCommonTypes.xsd

      The schema and wsdl both validate in Eclipse (using XML Catalog tool for
      Eclipse).

      Here's the relevant structure of my .war:

      WEB-INF/jax-ws-catalog.xml
      WEB-INF/schemas/common/1.0/CMDBCommonTypes.xsd
      WEB-INF/wsdl/1.0/CMDBDeviceDetails.wsdl

      The wsdl is:

      <wsdl:definitions ...>

      <wsdl:types>

      <xsd:schema
      xmlns:common="http://xml.xyz.com/cmdb/common/1.0/CMDBCommonTypes"
      targetNamespace="http://xml.xyz.com/cmdb/devicedetails/1.0/services">

      <xsd:import
      schemaLocation="http://somehost:8080/CMDB/schemas/common/1.0/CMDBCommonTypes.xsd
      "
      namespace="http://xml.xyz.com/cmdb/common/1.0/CMDBCommonTypes"/>

      ...

      </xsd:schema>

      The jax-ws-catalog.xml has:

      <catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog" prefer="system">
      <system
      systemId="http://somehost:8080/CMDB/schemas/common/1.0/CMDBCommonTypes.xsd"
      uri="schemas/common/1.0/CMDBCommonTypes.xsd" />
      </catalog>

        Activity

        Hide
        jitu added a comment -

        assigning to rama.

        Show
        jitu added a comment - assigning to rama.
        Hide
        ramapulavarthi added a comment -

        I am guessing you are doing standalone JAX-WS RI deployment and not using 109 deployment. In 109 deployment, Glassfish runtime fetches all the metadata from the primary wsdl using the catalog but not in RI deployment.

        In current JAX-WS deployment, we don't use catalog to fetch the metadata and expect all the metadata required for the service to be under WEB-INF/wsdl directory. It takes all such packaged documents and during wsdl publishing at runtime, for all the imports referencing the locally packaged document, the location is patched with a dynamic location ending with ?wsdl=1..n or ?xsd=1..n etc. If the metadata document references an external document (i.e not packaged), it does not patch the schemaLocation/wsdlLocation attribute. In your case, since it imports an external schema at http://somehost:8080/CMDB/schemas/common/1.0/CMDBCommonTypes.xsd, during wsdl publishing this location is not patched and hence soapUI has problem.

        One workaround is to use the catalog at on the client-side.

        Show
        ramapulavarthi added a comment - I am guessing you are doing standalone JAX-WS RI deployment and not using 109 deployment. In 109 deployment, Glassfish runtime fetches all the metadata from the primary wsdl using the catalog but not in RI deployment. In current JAX-WS deployment, we don't use catalog to fetch the metadata and expect all the metadata required for the service to be under WEB-INF/wsdl directory. It takes all such packaged documents and during wsdl publishing at runtime, for all the imports referencing the locally packaged document, the location is patched with a dynamic location ending with ?wsdl=1..n or ?xsd=1..n etc. If the metadata document references an external document (i.e not packaged), it does not patch the schemaLocation/wsdlLocation attribute. In your case, since it imports an external schema at http://somehost:8080/CMDB/schemas/common/1.0/CMDBCommonTypes.xsd , during wsdl publishing this location is not patched and hence soapUI has problem. One workaround is to use the catalog at on the client-side.
        Hide
        lhunath added a comment -

        Would this bug also affect wsimport? I cannot seem to get schemaLocations resolved against the catalog. As a result, our build is impossible to do offline and our productivity is halted whenever oasis or w3 or other servers go down.

        Show
        lhunath added a comment - Would this bug also affect wsimport? I cannot seem to get schemaLocations resolved against the catalog. As a result, our build is impossible to do offline and our productivity is halted whenever oasis or w3 or other servers go down.
        Hide
        Martin Grebac added a comment -

        Seems like Rama provided enough description into the nature of the issue, which leads to ways how to solve/workaround it. As for the wsimport problems, please file a new issue with reproducible testcase - don't expect these to have the same cause. Thanks.

        Show
        Martin Grebac added a comment - Seems like Rama provided enough description into the nature of the issue, which leads to ways how to solve/workaround it. As for the wsimport problems, please file a new issue with reproducible testcase - don't expect these to have the same cause. Thanks.

          People

          • Assignee:
            Martin Grebac
            Reporter:
            dwschulze
          • Votes:
            2 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: