[jbossws-issues] [JBoss JIRA] (JBWS-4029) Resolving inner xsd with absolute path using includes

[Jim Ma (JIRA)]

    [ https://issues.jboss.org/browse/JBWS-4029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13300096#comment-13300096 ] 

Jim Ma commented on JBWS-4029:
------------------------------

I'll reject this as we already discussed in the email and found a solution for this issue. 
{quote}
Did you try with <system systemId="http://www.wsdlgetproblem.org/xsd/test/content/includedcontent_a.xsd" uri="classpath:/schema/content/includedcontent_a.xsd"/> ?
Change include like <include schemaLocation="http://www.wsdlgetproblem.org/xsd/test/content/includedcontent_b.xsd"/>
I mentioned in previous email is changing this element in content.xsd ? There is already catalog configuration should work for this : <rewriteSystem systemIdStartString="http://www.wsdlgetproblem.org/xsd/test/content/" rewritePrefix="classpath:/schema/content/" />.
{quote}

> Resolving inner xsd with absolute path using includes 
> ------------------------------------------------------
>
>                 Key: JBWS-4029
>                 URL: https://issues.jboss.org/browse/JBWS-4029
>             Project: JBoss Web Services
>          Issue Type: Bug
>          Components: jbossws-cxf
>            Reporter: Viral Gohel
>         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.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.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)