[ https://issues.apache.org/jira/browse/CXF-7597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Freeman Fang resolved CXF-7597. ------------------------------- Resolution: Fixed Fix Version/s: 3.2.2 3.1.15 > Suspicious calls to ClassLoader.findResource when resolving absolute base and > actual URIs > ----------------------------------------------------------------------------------------- > > Key: CXF-7597 > URL: https://issues.apache.org/jira/browse/CXF-7597 > Project: CXF > Issue Type: Bug > Affects Versions: 3.2.1 > Reporter: Pavol Mederly > Assignee: Freeman Fang > Fix For: 3.1.15, 3.2.2 > > > 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 like > {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|https://github.com/Evolveum/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 > #11367|https://github.com/spring-projects/spring-boot/issues/11367]. > Even when Spring Boot is eventually fixed, {{classLoader.findResource(..)}} > calls are unnecessary overhead. > Please see > {{[URIResolverTest.testJARResolveBaseAndAbsolute|https://github.com/Evolveum/cxf/commit/44d99924db52f2a4b5bdacc41bd83b81bffb8cb4#diff-565a425d43d14b14b2dbb4a251b04697R92]}} > in the upcoming commit as well as the proposed > [fix|https://github.com/Evolveum/cxf/commit/44d99924db52f2a4b5bdacc41bd83b81bffb8cb4#diff-b7160a28d60b729a956bd1a5f5ffa351] > in {{URIResolver}}. -- This message was sent by Atlassian JIRA (v6.4.14#64029)