DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5060>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5060 Poorly formed filesystem URL with file:// issues Summary: Poorly formed filesystem URL with file:// issues Product: Cocoon 2 Version: 2.1alpha CVS Platform: PC OS/Version: Linux Status: NEW Severity: Blocker Priority: Other Component: core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Problem Description: -------------------- One certain platforms, the Entity Resolver delivers a poorly formed URL for the new filesystem location of the resolved entity. The resolver does load the catalog OK and it does resolve the entities OK - the pathname of the new systemId is correct. However, the new systemId starts with file:// and so "Failed to create InputSource: ... ERROR: Could not read resource". Symptoms: --------- Note that everything is OK via normal servlet running - the URL starts with file:/ and loads successfully. However, when running "build docs" it gets file:// and fails to load. Full symptoms are outlined in the appended Previous Discussion. Potential Solution: ------------------- See discussion below from Michael McKibben. Platform Reports: ----------------- Windows2K and SUN JDK 1.2.2 ... OK (CZ) Linux RedHat 7.1 and Blackdown j2sdk-1.3.1 ... bad (DC) Linux with Sun jdk 1.3.1 ... bad (DC) MacOS X.1.1 stock ... bad (JF) Workaround Solutions: --------------------- We have seen two ways to workaround the problem ... 1) change the parameter in documentation/cocoon.xconf --> <resolver class="org.apache.cocoon.components.resolver.ResolverImpl"> - <parameter name="catalog" value="/resources/entities/catalog"/> + <parameter name="catalog" value="//resources/entities/catalog"/> <parameter name="verbosity" value="2"/> </resolver> or even to + <parameter name="catalog" value="resources/entities/catalog"/> 2) provide the full context pathname in build.xml <java classname="org.apache.cocoon.Main" fork="true" dir="${build.context}"><!-- <arg value="-c."/> --> <arg value="-c/usr/local/cvs/xml-cocoon2/build/cocoon/documentation"/> Other Notes: ------------ The URL is built in components/resolver/ResolverImpl.java in the resolveEntity() method. Previous Discussion: -------------------- The following text is a summary of the thread: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100377479905511&w=2 ------------------------------------- Date: Mon, 22 Oct 2001 12:20:44 -0600 From: Michael McKibben <[EMAIL PROTECTED]> I think there is some general confusion on how 'file' URLs should be constructed. RFC 1738 describes the format explicitly as: fileurl = "file://" [ host | "localhost" ] "/" fpath So, "/usr/local/cocoon2" should be written as file:///usr/local/cocoon2 (Unix) file:///c:/usr/local/cocoon2 (Windows) Notice the '///'. This is because the host part of the URL is null. I could have written the URL as file://localhost/usr/local/cocoon2 (Unix) file://localhost/c:/usr/local/cocoon2 (Windows) and this would have worked also. Interestingly, with JDK1.3 new File("/usr/local/cocoon2").toURL().toString() (Unix) new File("c:/usr/local/cocoon2").toURL().toString() (Windows) returns 'file:/usr/local/cocoon2' (Unix) 'file:/c:/usr/local/cocoon2' (Windows) in apparent violation of the RFC! So now we have three equivalent ways to specify a file URL in Java: On Unix: file:///usr/local/cocoon2 file://localhost/usr/local/cocoon2 file:/usr/local/cocoon2 On Windows: file:///c:/usr/local/cocoon2 file://localhost/c:/usr/local/cocoon2 file:/c:/usr/local/cocoon2 Notice the file path must be absolute (which is why on Windows the drive specification must be specified.) Regards, --mike On Tue, 23 Oct 2001, David Crossley wrote: > I have discovered the cause of my problem with getting > "build docs" to work properly with the entity resolver. > Remember that it fails for me (but is OK for others) with > "Failed to create InputSource: file://usr/local/.......", and we > supsect the // to be a problem. I also noticed a strange > pathname for loading the catalog file with a "./" in the middle > of it. So i supected a bad path for the "contextDir" argument. > > Sure enough, if i hard-code the full pathname into build.xml > - <arg value=3D"-c."/> > + <arg value=3D"-c/usr/local/cvs/xml-cocoon2/build/cocoon/documentation"= /> > then the "build docs" works properly, and i finally see the > "catalog-test.html" with the ISOnum entity set being > resolved using the catalog. Hooray ... but why? > --David > > On Wed, 10 Oct 2001 Carsten wrote: >> Hi David, >> sorry I can't reproduce this here. Running under Windows2k >> everything is working fine and I always get file:/ urls. >> So, if someone with linux can have a look at it? >> Carsten >> >>> Gesendet: Mittwoch, 10. Oktober 2001 10:11 >>> An: [EMAIL PROTECTED] >>> Betreff: Re: entity resolution for Documentation build - almost >>> >>> Cartsen wrote: >>>> Hi David, >>>> I applied your patch to both cvs. Thanks! >>>> I think the problem lies indeed in the double slashes >>>> of your url (file://). Where is this url build? >>> >>> The URL is built in components/resolver/ResolverImpl.java >>> in the resolveEntity() method. Note that everything is OK >>> via normal servlet running - the URL starts with file:/ >>> However, when running "build docs" it gets file:// >>> >>> You would be able to see it yourself, if you try to >>> process the catalog-test.xml supplied with the last >>> patch. >>> cheers, David >>> >>>> Carsten >>>> >>>>> Gesendet: Montag, 8. Oktober 2001 14:17 >>>>> An: [EMAIL PROTECTED] >>>>> Betreff: Re: entity resolution for Documentation build - almost >>>>> >>>>> I am frustratingly close to getting entity catalogs working for >>>>> the documentation build, and need some help. Here are some >>>>> patches so that you can try for yourself. >>>>> >>>>> The patch to build.xml adds to the prepare-docs target >>>>> to copy the default catalog and its entities over to the >>>>> documentation build space. That is all that is required to >>>>> enable the entity resolver. >>>>> The patch to documentation/cocoon.xconf adds the config >>>>> parameters for catalog resolver. >>>>> >>>>> It is safe to apply those patches. Nothing is adversely affected. >>>>> The DTDs and other entities are already being resolved to >>>>> files relative to the XML instance document. >>>>> >>>>> However, if you declare a new entity set in an xdoc then >>>>> you will strike trouble. The entity resolver does deliver the >>>>> correct pathname for the entity set. However, we get ... >>>>> ----- >>>>> Failed to create InputSource: >>>>> file://usr/local/cvs/xml-cocoon2/build/cocoon/documentation/resou rces/entities/ISOnum.pen >>>> ----- >>>> Is the failure because of the double-slash file:// ... ??? >>>> The actual pathname is correct. >>>> >>>> When running via the normal webapp under Tomcat the >>>> InputSource is successful and the page is presented. >>>> The only difference is single slash rather than double slash >>>> after file: >>>> file:/usr/local/... >>>> >>>> As a convenience to facilitate testing of entity resolution for >>>> the documentation build, there is a Test document at >>>> documentation/xdocs/catalog-test.xml >>>> (see the side-panel button on 2.1-dev) >>>> >>>> cheers, David --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
