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 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.(URL.java:574)
>> at java.net.URL.(URL.java:464)
>> at java.net.URL.(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
