You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Craig Tataryn <cr...@tataryn.net> on 2010/02/05 01:03:09 UTC
Possible fix for resolving classpath schemas issues....
... 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
--
Craig Tataryn
site: http://www.basementcoders.com/
podcast:http://feeds.feedburner.com/TheBasementCoders
irc: ThaDon on freenode #basementcoders, ##wicket, #papernapkin
twitter: craiger
Re: Possible fix for resolving classpath schemas issues....
Posted by Craig Tataryn <cr...@tataryn.net>.
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 <dk...@apache.org> 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
> dkulp@apache.org
> 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
Re: Possible fix for resolving classpath schemas issues....
Posted by Daniel Kulp <dk...@apache.org>.
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