[
https://issues.apache.org/jira/browse/CXF-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Craig Tataryn updated CXF-2703:
-------------------------------
Attachment: URIResolver.java-jar-space-fix.patch
> cxf-codegen-plugin problem resolving schemas in jars that have spaces in the
> path (patch attached)
> --------------------------------------------------------------------------------------------------
>
> Key: CXF-2703
> URL: https://issues.apache.org/jira/browse/CXF-2703
> Project: CXF
> Issue Type: Bug
> Components: Tooling
> Affects Versions: 2.2.6
> 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"
> Reporter: Craig Tataryn
> Attachments: URIResolver.java-jar-space-fix.patch
>
>
> 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:
> {code}
> ---------------------------------------------------------------------------------------------
> 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)
> ------------------------------------------------------------------------------------------------
> {code}
> 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
