cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Possible fix for resolving classpath schemas issues....
Date Thu, 11 Feb 2010 21:52:52 GMT

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
dkulp@apache.org
http://www.dankulp.com/blog

Mime
View raw message