Red Hat Bugzilla – Bug 1069349
[GSS] (6.3.0) Schema imports in CXF can have naming conflicts in the URL used to retrieve them
Last modified: 2015-05-26 15:25:51 EDT
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.
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
Flagged as Known Issue as ticket unresolved at the time of writing the release note.
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
Verified on EAP 6.3.0 ER4. For verification used custom application - based on schema import test from CXF.
(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.
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.
Jader, sorry for the late reply. Any chance you can create a BZ or JIRA (upstream) issue with details for reproducing the issue? Thanks