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
| 