Re: deferred parsing loading files on unix -vs- windows?

Turns out this issue has more to do with the behavior of Tomcat-5 -vs- 
Tomcat-4.1.xx than any platform specifics.  It was working on Windows 
because I was using Tomcat-5 which extracts resources from a .jar file to 
Tomcat's work directory when they are requested from the classpath.  Not 
sure how Tomcat-5 does this, but that is why things were working.  When I 
used Tomcat-4.1.24 on Win2k, I got the same result as the partial stack 
trace below on Linux.

Richard and I are working on a solution to allow things to work in all 
cases so it doesn't have to count on container specific behavior.  Not sure 
if Tomcat-5's behavior is mandated by the servlet-2.4 spec or whether it is 
just being nice.  If the former, then it would be portable to other 
servlet-2.4 platforms.  If the latter, it might lead to vendor 
lock-in.  Either way, it should work for all cases and shouldn't even count 
on the servlet-2.4 spec to work.  It also needs to work outside a servlet 
environment.

I'll post an announcement of the fix when that is done.  If everything 
works out, the fix should be in the XMLC-2.2 final release.

Jake

At 12:21 AM 7/14/2003 -0500, you wrote:

>I've run into an issue with deferred parsing (or maybe just Java itself) 
>where deferred parsing doesn't seem to be able to load resources from the 
>classpath out of a .jar file on Linux where it works just fine on 
>Windows.  I'm getting a big stack trace.  Here is the relevant part...
>
>...
>...
>...
>Caused by: org.enhydra.xml.xmlc.XMLCRuntimeException: XMLC metadata file 
>parse failed: 
>file:file:/var/www/webapps/BarracudaDiscRack/WEB-INF/lib/barracuda_disc_rack.jar!/org/enhydra/barracuda/discRack/pres/xmlc/LoginHTML.xmlc
>         at 
> org.enhydra.xml.xmlc.deferredparsing.DocumentLoaderImpl.parseDocument(DocumentLoaderImpl.java:452)
>         at 
> org.enhydra.xml.xmlc.deferredparsing.DocumentLoaderImpl.getCacheEntry(DocumentLoaderImpl.java:165)
>         at 
> org.enhydra.xml.xmlc.deferredparsing.DocumentLoaderImpl.getDocument(DocumentLoaderImpl.java:217)
>         at 
> org.enhydra.barracuda.discRack.pres.xmlc.LoginHTMLImpl.buildDocument(LoginHTMLImpl.java:152)
>         at 
> org.enhydra.barracuda.discRack.pres.xmlc.LoginHTMLImpl.(LoginHTMLImpl.java:132)
>         at 
> org.enhydra.barracuda.discRack.pres.xmlc.LoginHTMLImpl.(LoginHTMLImpl.java:144)
>         ... 49 more
>Caused by: org.enhydra.xml.xmlc.XMLCException: XMLC metadata file parse 
>failed: 
>file:file:/var/www/webapps/BarracudaDiscRack/WEB-INF/lib/barracuda_disc_rack.jar!/org/enhydra/barracuda/discRack/pres/xmlc/LoginHTML.xmlc
>         at 
> org.enhydra.xml.xmlc.metadata.MetaDataDocument.parseMetaData(MetaDataDocument.java:182)
>         at 
> org.enhydra.xml.xmlc.deferredparsing.DocumentLoaderImpl.loadMetaData(DocumentLoaderImpl.java:406)
>         at 
> org.enhydra.xml.xmlc.deferredparsing.DocumentLoaderImpl.parseDocument(DocumentLoaderImpl.java:437)
>         ... 54 more
>Caused by: java.io.FileNotFoundException: 
>file:/var/www/webapps/BarracudaDiscRack/WEB-INF/lib/barracuda_disc_rack.jar!/org/enhydra/barracuda/discRack/pres/xmlc/LoginHTML.xmlc 
>(No such file or directory)
>...
>...
>...
>
>The file is definitely there and, again, it is found on Windows.  I 
>thought it might have something to do with files containing crlf's where 
>they should be lf's on Linux.  I used Ant's <fixcrlf> to fix things up, 
>but it seemed to make no difference.  Anyone have an idea as to what is 
>happening here?  Is it possibly a file permissions issue?  How do file 
>permissions work within jar archives on Linux?
>
>
>I'm attaching the full stack trace in a zip file...
>
>Jake