cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 5060] New: - Poorly formed filesystem URL with file:// issues
Date Sat, 24 Nov 2001 04:26:57 GMT
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: cocoon-dev@xml.apache.org
        ReportedBy: crossley@indexgeo.com.au


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 <mmckibben@ncube.com>
 
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: cocoon-dev@xml.apache.org
>>> 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: cocoon-dev@xml.apache.org
>>>>> 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message