Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
2.4.3
-
None
-
Moderate
Description
Hi,
I believe there is a bug in
org.apache.cxf.endpoint.dynamic.DynamicClientFactory#setupClasspath(StringBuilder, ClassLoader).
That method goes through the classloader hierarchy trying to find
classpath components. Among others, it checks the resource URLs returned
by java.net.URLClassLoader#getUrls(), trying to find a corresponding JAR
file.
However, its handling of the URLs is incorrect and fails if it
encounters a URL-encoded file path, for instance:
file:/C:/Program%20Files/Crapware/etc.
The code is:
URI uri = new URI(url.getProtocol(), null, url.getPath(), null, null);
file = new File(uri.getPath());
This doesn't work. The java.net.URI c'tor used here escapes characters
as necessary.
Correct code would use:
URI uri = new URI(url.toString());
file = new File(uri.getPath());
or
URI uri = new URI(url.getProtocol(), null,
URLDecoder.decode( url.getPath(), "UTF-8" ), null, null);
file = new File(uri.getPath());
.
Use case and why it fails
My code, running in an application container, creates a client using the
DynamicClientFactory from some WSDL.
That WSDL declares some (simple) types.
Those types are bound (via JAXB) to Java types that are part of my
application.
Code generation works fine, creating Adapters from the basic types to
the bound types.
But #setupClasspath() fails to find my application's JARs, because
they're loaded by the application classloader, a URLClassLoader, and are
on a path containing a space.
Consequently, the generated files cannot be compiled, because the bound
Java types cannot be resolved.