cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Tataryn <crai...@tataryn.net>
Subject Re: Possible fix for resolving classpath schemas issues....
Date Fri, 12 Feb 2010 22:02:32 GMT
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 <dkulp@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

Mime
View raw message