[xmlc] Re: Re: Re: Re: Windows file url problem

This is a multi-part message in MIME format...

------------=_1259862833-8018-2742
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Jacob,
After looking at the hasScheme() function, I thought the problem might 
be that I am running Windows as a virtual machine with a Linux box as 
the host. (using Sun's Virtual Box)

Sure enough deploying the application on a native windows installation 
(non-virtual) works as expected.

I will try the code change suggested below and see if it works on the 
virtual machine.

Thanks again for your help.


Yousif


Jacob Kjome wrote:
> Hmm... I'm unable to reproduce the issue.  I'm using Java 1.6.0_17, 
> Tomcat 6.0.14, and XMLC 2.3.1.
>
> The one main difference I'm seeing between your results and mine is 
> that in my stack trace, the path to the SSI file appears to be a valid 
> file URL path (with forward slashes) where your setup is producing 
> invalid ones (with backslashes). Here's the relevant part of the stack 
> trace (produced by pointing to a path not containing page02.ssi, 
> though it does load fine if I place the file there)...
>
> java.io.FileNotFoundException: 
> D:\tomcat6.1.4\webapps\xmlc\WEB-INF\classes\xmlc\page\includes\page02.ssi 
> (The system cannot find the path specified)
>     java.io.FileInputStream.open(Native Method)
>     java.io.FileInputStream.<init>(Unknown Source)
>     java.io.FileInputStream.<init>(Unknown Source)
>     sun.net.www.protocol.file.FileURLConnection.connect(Unknown Source)
>     sun.net.www.protocol.file.FileURLConnection.getInputStream(Unknown 
> Source)
>     org.enhydra.xml.io.InputSourceOps.openSystemId(InputSourceOps.java:74) 
>
>     org.enhydra.xml.io.InputSourceOps.open(InputSourceOps.java:94)
>
>
> Notice that in your stack trace, you hit InputSourceOps.java:76 where 
> I hit InputSourceOps.java:74.  See lines numbered below...
>
>         if (hasScheme(systemId)) {
>             URL url = new URL(systemId);
>             URLConnection conn = url.openConnection();
>             conn.setUseCaches(false); //avoid file locking on Windows
> 74:            return conn.getInputStream();
> 75:        } else {
> 76:            return new FileInputStream(systemId);
>         }
>
>     private static boolean hasScheme(String systemId) {
>         // Check for scheme, which must be before `/'.  Also handle 
> names with
>         // DOS drive letters (`D:', so 1-character schemes are not 
> allows.
>         int colonIdx = systemId.indexOf(':');
>         return ((colonIdx >= 2) && (colonIdx < systemId.indexOf('/')));
>     }
>
> What appears to be happening is that, for you, "if 
> (hasScheme(systemId))" is returning false, where it returns true for 
> me.  I take back what I said before about the stack trace showing a 
> bogus path.  I think that is actually the systemId being produced by 
> your setup (though I'm fairly certain that's a bug, maybe in the 
> version of Tomcat you are using???)....
>
> "file:\C:\Tomcat6.0\webapps\test-project\WEB-INF\classes\view\include\Body_bottom.html" 
>
>
> ...where mine is being returned as either...
>
> "file:/D:/tomcat6.1.4/webapps/xmlc/WEB-INF/classes/xmlc/page/includes/page02.ssi" 
>
> OR
> "file:///D:/tomcat6.1.4/webapps/xmlc/WEB-INF/classes/xmlc/page/includes/page02.ssi" 
>
>
> FileURLConnection then produces a path that a FileInputStream can 
> understand...
>
> "D:\tomcat6.1.4\webapps\xmlc\WEB-INF\classes\xmlc\page\includes\page02.ssi" 
>
>
> ...whereas in your case the FileInputStream gets created directly with 
> the bogus URL, including the scheme, with backslashes, which is why 
> you see the actual bogus path in the stack trace rather than a path 
> properly translated for a FileInputStream like what FileURLconnection 
> produced for my case.
>
> Interestingly, I tested the URL class and it accepts your bogus path 
> with backslashes (so maybe it isn't so bogus after all?).  So, really, 
> the hasScheme() method is being overly strict.  I think the fix is to 
> get rid of the hasScheme() method and change the other code to...
>
>
>         try {
>             URL url = new URL(systemId);
>             URLConnection conn = url.openConnection();
>             conn.setUseCaches(false); //avoid file locking on Windows
>             return conn.getInputStream();
>         } catch (MalformedURLException mue) {
>             return new FileInputStream(systemId);
>         }
>
> I'm planning on a 2.3.2 sometime in the near future (can't promise a 
> date).  If you can't wait, you can apply this fix yourself locally 
> until 2.3.2 comes out. See the source here...
>
> http://svn.forge.objectweb.org/cgi-bin/viewcvs.cgi/xmlc/trunk/xmlc/xmlc/modules/xmlc/src/org/enhydra/xml/io/InputSourceOps.java?rev=2039&view=log 
>
>
>
> Jake
>
>
> On 12/2/2009 5:37 PM, Yousif Seedham wrote:
>> Jacob,
>> Thanks for the reply.
>> I am using version 2.3.1 ( which i think is the latest..)
>>
>> from MANIFEST.MF:
>> Built-On: July 23 2008
>> Main-Class: org.enhydra.xml.xmlc.commands.xmlc.XMLC
>> Name: org/enhydra/xml/xmlc/
>> Specification-Title: Enhydra XMLC
>> Specification-Version: 2.3.1
>> Implementation-Version: 2.3.1
>>
>>
>> To avoid dealing with the slashes I moved the Body_bottom.html to the
>> same directory as the html page with the include tag.
>> (Note: This is not using xmlcReparseResourceDirs)
>> <!--#include file="Bottom_body.html" -->
>>
>> and I get the same stacktrace.
>>
>> Yousif
>>
>>
>> Jacob Kjome wrote:
>>> What version of XMLC are you using?
>>>
>>> What it's trying to do is generate a URL. There was a bug some time
>>> ago where URL.toExternalForm() was creating URLs that were invalid.
>>> The fix, oddly, was to use URL.toString(). Note that the following is
>>> the correct format for a file URL on Windows...
>>>
>>> file:/C:/Tomcat6.0/webapps/test-project/WEB-INF/classes/view/include/Body_bottom.html 
>>>
>>>
>>> OR
>>> file:///C:/Tomcat6.0/webapps/test-project/WEB-INF/classes/view/include/Body_bottom.html 
>>>
>>>
>>>
>>> Backslashes are definitely invalid in a URL. Note that the path
>>> FileInputStream spits out in a FileNotFoundException is somewhat
>>> deceiving because it doesn't know that that path is supposed to
>>> represent a URL. It just spits out slashes matching the System
>>> default. So take it with a grain of salt. The real issue probably has
>>> to do with appending two parts of the file path together; both
>>> including slashes. It probably ends up looking like this internally to
>>> the File object....
>>>
>>> "C:\Tomcat6.0\webapps\test-project\WEB-INF\classes\view\" +
>>> "include/Body_bottom.html"
>>>
>>> Notice how the first part has all backslashes and the second part has
>>> a forward slash. Don't get me wrong. The way you are coding your
>>> "include" statement is correct. It's a failure on XMLC's (or the
>>> JVM's) part to paste the base path together with the include path.
>>>
>>> It's possible you are using a version of XMLC that doesn't yet have
>>> the fix. Otherwise, if you are using an up-to-date version, then I can
>>> try to reproduce the issue and see what can be done. A possible
>>> workaround might be to add the "include" directory as one of the
>>> configured "xmlcReparseResourceDirs" (see [1] for an example of
>>> configuring this as a context-param) and then just use...
>>>
>>> <!--#include file="Body_bottom.html" -->
>>>
>>>
>>> That said, it looks like you are loading templates from the classpath,
>>> not via resource directories so that solution might not be applicable
>>> In any case, let me know if that helps. Otherwise, I'll try to
>>> reproduce this when I get home from work.
>>>
>>>
>>> [1]
>>> http://svn.forge.objectweb.org/cgi-bin/viewcvs.cgi/xmlc/trunk/xmlc/examples/tomcat/res/webapps/xmlc/WEB-INF/web.xml.in?rev=1591&view=auto 
>>>
>>>
>>>
>>> Jake
>>>
>>> On Wed, 02 Dec 2009 13:14:23 -0600
>>> Yousif Seedham <[email protected]> wrote:
>>>> hello,
>>>>
>>>> I am using deferred parsing and I am running into a problem with
>>>> include statements in my html document.
>>>>
>>>>
>>>> html code:
>>>> <!--#include file="include/Body_bottom.html" -->
>>>>
>>>> this works fine on linux(tomcat6, jdk1.6)
>>>> but on windows(tomcat6, jdk1.6) I get the following exception:
>>>>
>>>> org.enhydra.xml.xmlc.XMLCRuntimeException:
>>>> file:\C:\Tomcat6.0\webapps\test-project\WEB-INF\classes\view\include\Body_bottom.html 
>>>>
>>>> (The filename, directory name, or volume label syntax is incorrect)
>>>> org.enhydra.xml.xmlc.deferredparsing.DocumentLoaderImpl.parseDocument(DocumentLoaderImpl.java:590) 
>>>>
>>>>
>>>> org.enhydra.xml.xmlc.deferredparsing.DocumentLoaderImpl.checkCacheEntry(DocumentLoaderImpl.java:210) 
>>>>
>>>>
>>>> org.enhydra.xml.xmlc.deferredparsing.DocumentLoaderImpl.getDocument(DocumentLoaderImpl.java:238) 
>>>>
>>>>
>>>> view.LoginHTML.buildDocument(LoginHTML.java:211)
>>>> view.LoginHTML.<init>(LoginHTML.java:194)
>>>> view.LoginHTML.<init>(LoginHTML.java:204)
>>>> .
>>>> .
>>>> .
>>>>
>>>> java.io.FileNotFoundException:
>>>> file:\C:\Tomcat6.0\webapps\test-project\WEB-INF\classes\view\include\Body_bottom.html 
>>>>
>>>> (The filename, directory name, or volume label syntax is incorrect)
>>>> java.io.FileInputStream.open(Native Method)
>>>> java.io.FileInputStream.<init>(Unknown Source)
>>>> java.io.FileInputStream.<init>(Unknown Source)
>>>> org.enhydra.xml.io.InputSourceOps.openSystemId(InputSourceOps.java:76)
>>>> org.enhydra.xml.io.InputSourceOps.open(InputSourceOps.java:94)
>>>> org.enhydra.xml.xmlc.misc.SSIParsedStream.readIntoBuffer(SSIParsedStream.java:198) 
>>>>
>>>>
>>>> .
>>>> .
>>>> .
>>>>
>>>>
>>>> To get it to work on windows I had to define an absolute path:
>>>> <!--#include
>>>> file="/c://Tomcat6.0/webapps/test-project/WEB-INF/classes/view/include/Body_bottom.html" 
>>>>
>>>> -->
>>>>
>>>> It seems to me that windows does not like the
>>>> "file:" in
>>>> "file:\C:\Tomcat6.0\webapps\test-project\WEB-INF\classes\view\include\Body_bottom.html" 
>>>>
>>>>
>>>> which results if i use a relative path in my include.
>>>>
>>>> Any advice would be helpful...
>>>>
>>>>
>>>> Yousif
>>>>
>>>>
>>>

------------=_1259862833-8018-2742
Content-Type: text/plain; charset="UTF-8"; name="message-footer.txt"
Content-Disposition: inline; filename="message-footer.txt"
Content-Transfer-Encoding: quoted-printable


--
You receive this message as a subscriber of the [email protected] mailing list=
.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=3Dhelp
OW2 mailing lists service home page: http://www.ow2.org/wws

------------=_1259862833-8018-2742--