cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (CXF-7597) Suspicious calls to ClassLoader.findResource when resolving absolute base and actual URIs
Date Thu, 04 Jan 2018 12:15:00 GMT


ASF GitHub Bot commented on CXF-7597:

mederly opened a new pull request #363: [CXF-7597] Fix suspicious class loader findResource

This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:

> Suspicious calls to ClassLoader.findResource when resolving absolute base and actual
> -----------------------------------------------------------------------------------------
>                 Key: CXF-7597
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>    Affects Versions: 3.2.1
>            Reporter: Pavol Mederly
> When {{URIResolver.resolve(..)}} is called with both {{baseUriStr}} and {{uriStr}} containing
absolute URIs, e.g.
> {quote}
> # *baseUriStr* = jar:file:/C:/midpoint/tgit/cxf/core/target/test-classes/org/apache/cxf/resource/resources/helloworld.bpr!/wsdl/hello_world.wsdl
> # *uriStr* = jar:file:/C:/midpoint/tgit/cxf/core/target/test-classes/org/apache/cxf/resource/resources/helloworld.bpr!/wsdl/hello_world_2.wsdl
> {quote}
> then it makes suspicious calls to a class loader, trying to find resources with names
> {quote}
> # jar:file:/C:/midpoint/tgit/cxf/core/target/test-classes/org/apache/cxf/resource/resources/helloworld.bpr!/wsdl/hello_world_2.wsdl
> # /jar:file:/C:/midpoint/tgit/cxf/core/target/test-classes/org/apache/cxf/resource/resources/helloworld.bpr!/wsdl/hello_world_2.wsdl
> # jar:file:/C:/midpoint/tgit/cxf/core/target/test-classes/org/apache/cxf/resource/resources/helloworld.bpr!/wsdl/hello_world_2.wsdl
> {quote}
> In our case (when used as part of the [midPoint|]
product) the situation is like this:
> Resolving:
> {quote}
> # *baseUriStr* = jar:file:/C:/tmp/mp/lib/midpoint.war!/WEB-INF/lib/schema-3.7.jar!/xml/ns/public/common/common-3.xsd
> # *uriStr* = jar:file:/C:/tmp/mp/lib/midpoint.war!/WEB-INF/lib/schema-3.7.jar!/prism/xml/ns/public/types-3.xsd
> {quote}
> leads first to the resolution of obviously wrong URL:
> bq. jar:file:/C:/tmp/mp/lib/midpoint.war!jar:file:/C:/tmp/mp/lib/midpoint.war!/WEB-INF/lib/schema-3.7.jar!/prism/xml/ns/public/types-3.xsd
> (note the two midpoint.war segments there)
> and then to the resolution of the following resource name (via class loader):
> bq. jar:file:/C:/tmp/mp/lib/midpoint.war!/WEB-INF/lib/schema-3.7.jar!/prism/xml/ns/public/types-3.xsd
> Note that as per ClassLoader javadocs, "The name of a resource is a '/'-separated path
name that identifies the resource." Although formally the above URIs match this definition,
some class loader implementations, namely the one in Spring Boot which we use in midPoint,
react to such requests in an unexpected way, returning wrong (unrelated) content. The result
is that {{URIResolver.resolve(..)}} returns the wrong content as well. See [Spring Boot issue
> Even when Spring Boot is eventually fixed, {{classLoader.findResource(..)}} calls are
unnecessary overhead.
> Please see {{[URIResolverTest.testJARResolveBaseAndAbsolute|]}}
in the upcoming commit as well as the proposed [fix|]
in {{URIResolver}}.

This message was sent by Atlassian JIRA

View raw message