Hey Dan, it appears 2.2.7-SNAPSHOT has introduced some other some schema resolution/validation problems. My coworker Rebecca has been debugging and to find out where/why it's breaking and then report back with her findings.
Thanks, Craig. On Thu, Feb 11, 2010 at 3:52 PM, Daniel Kulp <[email protected]> wrote: > > Craig, > > Any chance you could retest this with 2.2.7-SNAPSHOT? > > I added some code to escape the URL's better (convert spaces to %20 and other > fun things) last week some time. Thus, this may now be fixed already. > > That said, I took the example off the jira again and reran it in a directory > with a space and with my m2 repo moved into a director with a space and didn't > have any issues. I did a grep for "classpath" and didn't really see > anything other than in your spring beans. Thus, I'm not sure where that > protocol would have come from. Is there a full stack trace? > > Dan > > > On Thu February 4 2010 7:03:09 pm Craig Tataryn wrote: >> ... when XSDs are held within jar files that have a space in their path. >> >> Here is the scenario: Dan did a patch for an issue I logged [1] >> involving the proper resolution of XSDs held in a separate maven >> module (or any jar on the classpath for that matter) instead of the >> XSDs existing directly in the module where cxf-codegen-plugin is being >> invoked. It worked great for me, but oddly enough only when I invoked >> an "mvn clean install" from the parent project. If I went down into >> the actual module that was setup for cxf-codegen-plugin and try to >> clean install, it would bomb with: >> >> --------------------------------------------------------------------------- >> ------------------ org.apache.maven.lifecycle.LifecycleExecutionException: >> Thrown by JAXB >> >> : unknown protocol: classpath >> >> . >> . >> Caused by: java.net.MalformedURLException: unknown protocol: classpath >> at java.net.URL.<init>(URL.java:574) >> at java.net.URL.<init>(URL.java:464) >> at java.net.URL.<init>(URL.java:413) >> at >> org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source) >> at >> org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(Unknown >> Source) >> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown >> Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown >> Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at >> org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at >> org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) >> at >> com.sun.tools.xjc.reader.internalizer.DOMForest.parse(DOMForest.java:394) >> >> --------------------------------------------------------------------------- >> --------------------- >> >> I debugged like crazy, found where things were going wrong. I found a >> bug [2] which kind of described the problem, i.e. a jar on the >> classpath you are trying to get a resource URL for has a space in it's >> path. So what I did was I changed my Maven repo from D:\Documents and >> Settings\.... to D:\m2repo, a path without spaces. Lo and behold, >> everything worked peachy after that. >> >> So, attached is an attempt at a patch to URIResolver in order to fix >> the problem. That being said, I have no way to test this patch in >> order to see if it works. Why? Because if I make the fix myself to >> the 2.2.6 code on my system, then mvn clean install a new version into >> my local repo, then run a debug session when it gets to >> AbstractWrapperWSDLLocator.getImportInputSource, the parentLocation >> parameter doesn't include a classpath:/ prefix, instead it just >> contains the relative path found within the XSD, and I get a >> "FileNotFound" type error. No clue why. >> >> People on Windows (because of the m2 repo being under Documents and >> Settings by default; a path containing spaces) would definitely face >> the problem I'm trying to solve. I'm not completely sure if it's JDK >> vendor related, but on my project I'm using IBM jvm, here's my >> environment: >> >> ----------------------------------------- >> $ mvn --version >> Apache Maven 2.2.1 (r801777; 2009-08-06 14:16:01-0500) >> Java version: 1.6.0 >> Java home: D:\Program Files\IBM\RAD75\jdk\jre >> Default locale: en_US, platform encoding: Cp1252 >> OS name: "windows xp" version: "5.1 build 2600 service pack 3" arch: >> "x86" Family: "windows" >> ----------------------------------------- >> >> So, if anyone would be so kind as to try to replicate the problem, >> then apply the patch and see if the problem is resolved, that would be >> great. >> >> Steps to reproduce: >> 1) download the sample project from the JIRA issue [1] >> 2) crack open the pom.xml file from CXFSchemaRefProblemPom, update the >> cxf versions to 2.2.6 >> 3) crack open the pom.xml from CXFSchemaRefProblemWar and comment out >> all the extraargs except for -verbose >> 4) "mvn clean install" from CXFSchemaRefProblemPom, should build cleanly >> 5) "mvn clean install -e" from CXFSchemaRefProblemWar, you should get >> the classpath protocol error >> 6) apply my patch, install the change locally, try step 5 again. >> >> Thanks, >> >> Craig >> >> [1] - https://issues.apache.org/jira/browse/CXF-2599 >> [2] - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6506304 > > -- > Daniel Kulp > [email protected] > http://www.dankulp.com/blog > -- Craig Tataryn site: http://www.basementcoders.com/ podcast:http://feeds.feedburner.com/TheBasementCoders irc: ThaDon on freenode #basementcoders, ##wicket, #papernapkin twitter: craiger
