[CXF-7597] Suspicious calls to ClassLoader.findResource when resolving absolute base and actual URIs

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.2.1
• Fix Version/s: 3.2.2, 3.1.15
• Estimated Complexity: Unknown
• Flags: Patch
• Assignee: Freeman Yue Fang
• Reporter: Pavol Mederly
• Created: 21/Dec/17 17:48
• Updated: 13/Jan/18 16:20
• Resolved: 13/Jan/18 11:07

Description

When URIResolver.resolve(..) is called with both baseUriStr and uriStr containing absolute URIs, e.g.

1. baseUriStr = jar:file:/C:/midpoint/tgit/cxf/core/target/test-classes/org/apache/cxf/resource/resources/helloworld.bpr!/wsdl/hello_world.wsdl
2. uriStr = jar:file:/C:/midpoint/tgit/cxf/core/target/test-classes/org/apache/cxf/resource/resources/helloworld.bpr!/wsdl/hello_world_2.wsdl

then it makes suspicious calls to a class loader, trying to find resources with names like

1. jar:file:/C:/midpoint/tgit/cxf/core/target/test-classes/org/apache/cxf/resource/resources/helloworld.bpr!/wsdl/hello_world_2.wsdl
2. /jar:file:/C:/midpoint/tgit/cxf/core/target/test-classes/org/apache/cxf/resource/resources/helloworld.bpr!/wsdl/hello_world_2.wsdl
3. jar:file:/C:/midpoint/tgit/cxf/core/target/test-classes/org/apache/cxf/resource/resources/helloworld.bpr!/wsdl/hello_world_2.wsdl

In our case (when used as part of the midPoint product) the situation is like this:

Resolving:

1. baseUriStr = jar:file:/C:/tmp/mp/lib/midpoint.war!/WEB-INF/lib/schema-3.7.jar!/xml/ns/public/common/common-3.xsd
2. uriStr = jar:file:/C:/tmp/mp/lib/midpoint.war!/WEB-INF/lib/schema-3.7.jar!/prism/xml/ns/public/types-3.xsd

leads first to the resolution of obviously wrong URL:

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):

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.

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.

Issue Links

• links to: GitHub Pull Request #363