Dan Diephouse - 30/Aug/06 01:55 PM This is fixed in SVN now. A build is posted here: http://snapshots.repository.codehaus.org/org/codehaus/xfire/xfire-all/1.2-SNAPSHOT/xfire-all-1.2-20060830.184652-12.jar

Michael Vorburger - 30/Aug/06 04:06 PM Dan - I just looked at this... tried the JAR and SVN update. Comments: That resolver.getURI().toURL() in XFireClientFactoryBean is prone to NPE (two maybe?) - in fact its the first thing that happened to me... when using a "hello.wsdl" that looked relative, but could not be found. How about a clear error message in that case? Unfortunately, even when using a "/hello.wsdl" I didn't seem to work, but here it failed with: Could not find resource '/hello.wsdl' relative to '', although I do believe I have that on the classpath... weired. A simple getClass().getResource("/hello.wsdl") find it, but that Resolver (whew!) does not. If it would work, an "interesting" corner case to test could be whether you could specify a WSDL that imports a XSD - that would require the base thing to be set correctly. Anyway. Not a burning issue for me, but I thought I'd provide some feedback as I just briefly tested this.

Dan Diephouse - 30/Aug/06 04:28 PM Good point on the NPE and the error message. I'll get that improved. I'm not sure whats happening on the classpath resource. I'll dig into it more.

Dan Diephouse - 01/Sep/06 03:32 PM OK, I even added a unit test for classpath resources and things work great. Additionally I added some logic to support "classpath:foo.wsdl" urls. You can give this build a whirl, but I'm pretty sure that its something with your environment if this doesn't work: http://snapshots.repository.codehaus.org/org/codehaus/xfire/xfire-all/1.2-SNAPSHOT/xfire-all-1.2-20060901.201314-13.jar