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. OC. -- I can't decide whether to commit suicide or go bowling. -- Florence Henderson
