[jira] [Updated] (CXF-7597) Suspicious calls to ClassLoader.findResource when resolving absolute base and actual URIs
[
https://issues.apache.org/jira/browse/CXF-7597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavol Mederly updated CXF-7597:
---
Description:
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}}.
was:
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,
[jira] [Updated] (CXF-7597) Suspicious calls to ClassLoader.findResource when resolving absolute base and actual URIs
[
https://issues.apache.org/jira/browse/CXF-7597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavol Mederly updated CXF-7597:
---
Description:
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}} in the upcoming
commit as well as the proposed fix in {{URIResolver}}.
was:
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
