You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Craig Tataryn (JIRA)" <ji...@apache.org> on 2010/03/10 17:11:30 UTC

[jira] Created: (CXF-2703) cxf-codegen-plugin problem resolving schemas in jars that have spaces in the path (patch attached)

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


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.


[jira] Resolved: (CXF-2703) cxf-codegen-plugin problem resolving schemas in jars that have spaces in the path (patch attached)

Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CXF-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp resolved CXF-2703.
------------------------------

       Resolution: Fixed
    Fix Version/s: 2.2.7

> 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
>            Assignee: Daniel Kulp
>             Fix For: 2.2.7
>
>         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.


[jira] Assigned: (CXF-2703) cxf-codegen-plugin problem resolving schemas in jars that have spaces in the path (patch attached)

Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CXF-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp reassigned CXF-2703:
--------------------------------

    Assignee: Daniel Kulp

> 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
>            Assignee: Daniel Kulp
>         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.


[jira] Updated: (CXF-2703) cxf-codegen-plugin problem resolving schemas in jars that have spaces in the path (patch attached)

Posted by "Craig Tataryn (JIRA)" <ji...@apache.org>.
     [ 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.