Bug 1069349 - [GSS] (6.3.0) Schema imports in CXF can have naming conflicts in the URL used to retrieve them
Summary: [GSS] (6.3.0) Schema imports in CXF can have naming conflicts in the URL used...
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Web Services
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ER4
: EAP 6.3.0
Assignee: Alessio Soldano
QA Contact: Rostislav Svoboda
Russell Dickenson
Depends On:
Blocks: 1069352 1084169 1087653 1100931 1103627
TreeView+ depends on / blocked
Reported: 2014-02-24 19:41 UTC by Kyle Lape
Modified: 2018-12-06 15:56 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
A bug in previous releases of JBoss EAP 6 created naming conflicts in URLs when importing schema in CXF. This issue has been addressed in this release of the product.
Clone Of:
: 1069352 1084169 1100931 (view as bug list)
Last Closed: 2014-06-28 15:45:01 UTC
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Apache JIRA CXF-4910 0 None None None Never

Description Kyle Lape 2014-02-24 19:41:16 UTC
The following description is copied from CXF-4910.

A following example results in incorrect behavior:

WSDLGetUtils.updateSchemaImports() uses a map for caching processed schemata.
A service built from following path layout



- Wsdl.wsld imports z/Types.xsd(NS: http://example.com/NS1) using relative path
- z/Types.xsd imports z/Types.xsd(NS: http://example.com/NS2) using relative path (i.e. imports z/z/Types.xsd)

results in incorrect serving of service definition when querying the endpoint.

The link from wsdl to import points to "?xsd=z/Types.xsd".

<wsdl:definitions xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://example.com/Service/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" name="Service" targetNamespace="http://example.com/Service/">
    <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://example.com/Service/" xmlns:sty="http://example.com/StructTypes" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" targetNamespace="http://example.com/Service/">
      <xsd:import namespace="http://example.com/StructTypes" schemaLocation="http://localhost:8080/Service?xsd=z/Types.xsd"/>

The link from z/Types.xsd points again to itself "?xsd=z/Types.xsd" (same content is served).
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
    <xsd:import namespace="http://example.com/BaseTypes" schemaLocation="http://localhost:8080/Service?xsd=z/Types.xsd"/>

This is because the WSDLGetUtils cuts of the schemata processing on the first import because relative path is used as key identifier in the schema map.

I suspect the same applies for the WSDL imports in WSDLGetUtils.updateDefinition() due to caching the definitions in the definition map.

Comment 3 Kyle Lape 2014-04-15 18:13:05 UTC
Note that while CXF-4910 was mostly fixed in CXF 2.7.11, there was another commit to complete the fix after 2.7.11 was tagged.

git commit ID: 80e89da70ac57017afaf712d2559d21a43e0b66a

Comment 4 Scott Mumford 2014-04-22 23:22:07 UTC
Flagged as Known Issue as ticket unresolved at the time of writing the release note.

Comment 5 Kabir Khan 2014-04-25 15:22:16 UTC
Setting to MODIFIED for ER4 (I believe the component upgrade solves this) since ER3 is the new beta candidate, and is ER2+beta blockers only

Comment 6 Jan Blizňák 2014-05-15 15:08:55 UTC
Verified on EAP 6.3.0 ER4.
For verification used custom application - based on schema import test from CXF.

Comment 7 Jim Ma 2014-05-21 04:41:55 UTC
(In reply to Kyle Lape from comment #3)
> Note that while CXF-4910 was mostly fixed in CXF 2.7.11, there was another
> commit to complete the fix after 2.7.11 was tagged.
> git commit ID: 80e89da70ac57017afaf712d2559d21a43e0b66a

Just to add more details about this issue. This BZ is actually created for the schema import issue which Kyle provided the test case to reproduce the customer issue.  This git commit is actually fixed for another "schema include" issue Kyle spotted later after this. IMO, this should be created another BZ to track.

Comment 8 Jader 2015-05-04 23:26:51 UTC
This bug fix generates another bug. When importing second level xsd in a schema file, the schemaLocation attribute resolves wrong relative path, using ../../ or wathever. This bug persists in 6.3.x and 6.4.

Comment 9 Alessio Soldano 2015-05-26 19:25:51 UTC
Jader, sorry for the late reply. Any chance you can create a BZ or JIRA (upstream) issue with details for reproducing the issue?

Note You need to log in before you can comment on or make changes to this bug.