Uploaded image for project: 'JBoss Web Services'
  1. JBoss Web Services
  2. JBWS-4029

Resolving inner xsd with absolute path using includes



    • Bug
    • Resolution: Won't Do
    • Major
    • None
    • None
    • jbossws-cxf
    • None
      • Attached reproducer code, xsd_catalog_resolving_with_catalog.zip.
      • Deploy this on EAP 6.4.0.
      • There is a patched file, WSDLGetUtils.java in the attachment.


      CXF-6234 fixes the writing a new document and replaces public system id’s with class path id’s. However, before doing so, it checks whether the URL to rewrite is indeed in the set of resolved URL’s and schema’s. This set is not resolved correctly.
      It seems that the method WSDLGetUtils#getAndSaveRelativeSchemaLocationIfCatalogResolved is the culprit. It all depends on how the ‘doneSchemas’ hashmap is ordered. By some java source code investigation we found out how the hashing mechanism (and thus the sorting) in the ConcurrentHashMap works. This is how we devised the replicator. It uses such file names and URLs that the keys in the map are sorted in such a way that the problem occurs.
      Expected behavior when querying with the following URL: http://localhost:8080/jboss-helloworld-ws?xsd=http://www.wsdlgetproblem.org/xsd/test/content/content.xsd,

      <schema elementFormDefault="qualified" targetNamespace="http://www.wsdlgetproblem.org/xsd/test/content" version="1.0.0"><include schemaLocation="http:// localhost:8080/jboss-helloworld-ws?xsd=http://www.wsdlgetproblem.org/xsd/test/content/includedcontent_a.xsd"/><include schemaLocation="http:// localhost:8080/jboss-helloworld-ws?xsd=http://www.wsdlgetproblem.org/xsd/test/content/includedcontent_b.xsd"/></schema>

      But.. I do get:
      <schema elementFormDefault="qualified" targetNamespace="http://www.wsdlgetproblem.org/xsd/test/content" version="1.0.0"><include schemaLocation="includedcontent_a.xsd"/><include schemaLocation="includedcontent_b.xsd"/></schema>

      • The trick in the reproducer is to find such filenames that they line up in a certain order in the ConcurrentHashMap. Most of the XSD/WSDL projects work, although there are far too many entries on the doneSchema's (as shown in the screenshot).

      To make the reproducer we tried to figure out which orders are correct and which not. Next we looked up the source of ConcurrentHashMap, checked its key hashing mechanism and constructed the path/file names of the XSD in such a way that they are sorted in the problematic order. It's not easy to trigger the right conditions.




            Unassigned Unassigned
            rhn-support-vgohel Viral Gohel
            0 Vote for this issue
            2 Start watching this issue