Bug 1100931 - [GSS] (6.3.0) Schema includes in CXF can have naming conflicts in the URL used to retrieve them
Summary: [GSS] (6.3.0) Schema includes in CXF can have naming conflicts in the URL use...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Web Services
Version: 6.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ER6
: EAP 6.3.0
Assignee: Alessio Soldano
QA Contact: Rostislav Svoboda
Russell Dickenson
URL:
Whiteboard:
Depends On: 1069349
Blocks: 1069352 1084169 1087653 1103627
TreeView+ depends on / blocked
 
Reported: 2014-05-24 00:39 UTC by Kyle Lape
Modified: 2018-12-06 16:36 UTC (History)
8 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 resolved with an upgrade to the Apache CXF component.
Clone Of: 1069349
Environment:
Last Closed: 2014-06-28 15:26:10 UTC
Type: Bug


Attachments (Terms of Use)
Patch to be applied on CXF 2.7.11-redhat2 (24.48 KB, text/plain)
2014-06-02 16:43 UTC, Emmanuel Hugonnet (ehsavoie)
no flags Details


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

Description Kyle Lape 2014-05-24 00:39:47 UTC
+++ This bug was initially created as a clone of Bug #1069349 +++

The following description is copied from CXF-4910.

A following example results in incorrect behavior:

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

Wsdl.wsdl
z/Types.xsd
z/z/Types.xsd

Where

- 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/">
  <wsdl:types>
    <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"/>
    </xsd:schema>
    ...
  </wsdl:types>
  ...
</wsdl:definitions>

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" 
  xmlns:tns="http://example.com/StructTypes" 
  xmlns:bty="http://example.com/BaseTypes" 
  targetNamespace="http://example.com/StructTypes">
    <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.

---------------------------------

This is the same issue as CXF-4910 except for <includes> instead of <imports>.  The upstream commit:

https://github.com/apache/cxf/commit/80e89da70ac57017afaf712d2559d21a43e0b66a

Comment 1 Emmanuel Hugonnet (ehsavoie) 2014-06-02 16:43:17 UTC
Created attachment 901508 [details]
Patch to be applied on CXF 2.7.11-redhat2

Comment 3 Kabir Khan 2014-06-03 16:42:09 UTC
Fixed by upgrade https://bugzilla.redhat.com/show_bug.cgi?id=1103627

Comment 4 Jan Blizňák 2014-06-12 12:40:56 UTC
Verified on 6.3.0.ER7

Using reproducers from customer portal, I manually verified that relative address is now resolved correctly.


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