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

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

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

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
>>>
>>>
>>

------------=_1259819736-8018-2639
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

------------=_1259819736-8018-2639--