cxf-dev mailing list archives

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


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?


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: unknown protocol: classpath
>         at<init>(
>         at<init>(
>         at<init>(
>         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
> ---------------------------------------------------------------------------
> ---------------------
> 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] -
> [2] -

Daniel Kulp

View raw message