Resolving inner xsd with absolute path using includes ----------------------------------------------------- Key: JBWS-4032 URL: https://issues.jboss.org/browse/JBWS-4032 Project: JBoss Web Services Issue Type: Enhancement Components: jbossws-cxf Reporter: Viral Gohel Fix For: jbossws-cxf-5.2.0.Final Attachments: xsd_catalog_resolving_with_catalog.zip 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.o..., <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/... schemaLocation="http:// localhost:8080/jboss-helloworld-ws?xsd=http://www.wsdlgetproblem.org/xsd/... 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. The real case is complicated. It counts around 30 XSD's that refer to each other for one case. Moreover, I've got 26 other of these cases to handle coming years of development. Are you suggesting that I would permute over the catalog try to guess a working combination for all 26 of them? I think we can both agree this is not manageable.