[JBoss JIRA] (JBWS-4032) Resolving inner xsd with absolute path using includes
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-4032?page=com.atlassian.jira.plugin.... ]
Alessio Soldano updated JBWS-4032:
----------------------------------
Fix Version/s: jbossws-cxf-5.2.0.Final
> 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/..."/><include schemaLocation="http:// localhost:8080/jboss-helloworld-ws?xsd=http://www.wsdlgetproblem.org/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.
> 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.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
8 years, 1 month
[JBoss JIRA] (JBWS-4032) Resolving inner xsd with absolute path using includes
by Viral Gohel (JIRA)
Viral Gohel created JBWS-4032:
---------------------------------
Summary: 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
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/..."/><include schemaLocation="http:// localhost:8080/jboss-helloworld-ws?xsd=http://www.wsdlgetproblem.org/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.
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.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
8 years, 1 month
[JBoss JIRA] (JBWS-4031) Avoid array allocation in SubjectCreatingPolicyInterceptor
by Philippe Marschall (JIRA)
Philippe Marschall created JBWS-4031:
----------------------------------------
Summary: Avoid array allocation in SubjectCreatingPolicyInterceptor
Key: JBWS-4031
URL: https://issues.jboss.org/browse/JBWS-4031
Project: JBoss Web Services
Issue Type: Patch
Components: jbossws-cxf
Reporter: Philippe Marschall
{{SubjectCreatingPolicyInterceptor#getPrincipal(Principal, Subject)}} converts a {{Set}} to an array just to get the first element. This is unnecessary and can easily be done with an {{Iterator}} which avoids the array creation.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month