cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alessio Soldano (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CXF-4910) Bad handling of Schema imports (WSDLGetInterceptor)
Date Mon, 24 Mar 2014 15:05:45 GMT

     [ https://issues.apache.org/jira/browse/CXF-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Alessio Soldano updated CXF-4910:
---------------------------------

    Fix Version/s: 2.6.14
                   2.7.11
                   3.0.0

> Bad handling of Schema imports (WSDLGetInterceptor)
> ---------------------------------------------------
>
>                 Key: CXF-4910
>                 URL: https://issues.apache.org/jira/browse/CXF-4910
>             Project: CXF
>          Issue Type: Bug
>          Components: Simple Frontend
>    Affects Versions: 2.7.3
>         Environment: Windows
>            Reporter: Rastislav Cesnek
>            Assignee: Jim Ma
>             Fix For: 3.0.0, 2.7.11, 2.6.14
>
>
> While doing my experiments with completely dynamic service creation from WSDL only, I
found suspicious code in WSDLGetInterceptor regarding schema cacheing. 
> A following example results in incorrect behavior:
> Namely:
> WSDLGetUtils.updateSchemaImports() uses a map for caching processed schemata.
> A service built from following path layout
> {code}
> Wsdl.wsdl
> z/Types.xsd
> z/z/Types.xsd
> {code}
> 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".
> {code:xml}
> <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"/>
> [...SNIP...]
> {code}
> The link from z/Types.xsd points again to itself "?xsd=z/Types.xsd" (same content is
served).
> {code:xml}
> <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"/>
> [...SNIP...]
> {code}
> 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 message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message