You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Pavol Mederly (JIRA)" <ji...@apache.org> on 2014/10/02 12:32:33 UTC
[jira] [Updated] (CXF-6034) Wrong schemaLocation if jax-ws-catalog
is used
[ https://issues.apache.org/jira/browse/CXF-6034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pavol Mederly updated CXF-6034:
-------------------------------
Attachment: wsdl_first.zip
Demonstration project (modified wsdl_first sample). After running it, point your browser to http://localhost:9090/CustomerServicePort?wsdl and see the result.
> Wrong schemaLocation if jax-ws-catalog is used
> ----------------------------------------------
>
> Key: CXF-6034
> URL: https://issues.apache.org/jira/browse/CXF-6034
> Project: CXF
> Issue Type: Bug
> Components: Simple Frontend
> Affects Versions: 3.0.1
> Reporter: Pavol Mederly
> Attachments: wsdl_first.zip
>
>
> When
> - using a WSDL-first approach,
> - defining endpoints so that *your* (not generated) WSDL is provided,
> - using jax-ws-catalog
> the WSDL given out to the client is sometimes incorrect.
> Specifically, having entries in jax-ws-catalog like these
> {code}
> <public publicId="http://test.com/main/schema" uri="../main/schema.xsd" />
> <system systemId="http://test.com/main/schema" uri="../main/schema.xsd" />
> <public publicId="http://test.com/auxiliary/schema" uri="../auxiliary/auxiliary.xsd" />
> <system systemId="http://test.com/auxiliary/schema" uri="../auxiliary/auxiliary.xsd" />
> {code}
> And having XSD imports in your types section of WSDL like these:
> {code}
> <xs:schema targetNamespace="http://test.com/main/customer-service" ...>
> <!-- this fails -->
> <xsd:import namespace="http://test.com/main/schema" schemaLocation="http://test.com/main/schema"/>
> <!-- this works -->
> <xsd:import namespace="http://test.com/auxiliary/schema" schemaLocation="http://test.com/auxiliary/schema"/>
> </xs:schema>
> {code}
> The resulting WSDL is like this (showing only the relevant part):
> {code}
> <xs:schema targetNamespace="http://test.com/main/customer-service" ...>
> <!-- this fails -->
> <xsd:import namespace="http://test.com/main/schema" schemaLocation="http://test.com/main/schema"/>
> <!-- this works -->
> <xsd:import namespace="http://test.com/auxiliary/schema" schemaLocation="http://localhost:9090/CustomerServicePort?xsd=http://test.com/auxiliary/schema"/
> </xs:schema>
> {code}
> (note the wrong schemaLocation attribute in the first import)
> The problem occurs when the URI of the resource being imported is the same as (except for its last segment) the URI of the WSDL itself. In this case, *http://test.com/main/*schema vs. *http://test.com/main/*customer-service.
> I was able to fix this preliminarily by disabling "optimization" used in WSDLGetUtils.findSchemaLocation, namely this code:
> {code}
> if (docBase != null && imp.getReferencedSchema() != null) {
> try {
> String baseURI = URLDecoder.decode(UrlUtils.getStem(docBase), "utf-8");
> String importURI = URLDecoder.decode(imp.getReferencedSchema().getDocumentBaseURI(), "utf-8");
> if (importURI.contains(baseURI)) {
> schemaLocationURI = importURI.substring(baseURI.length() + 1);
> }
> } catch (Exception e) {
> //ignore
> }
> }
> {code}
> However, I'm sure this is in fact a workaround; there should exist a cleaner solution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)