Hi all, FYI, in case you run into this kind of mysterious error, here's what was happening in our case. The problem DID have to do with the upper/lowercase 'E' in the URL.
When starting up the server (Tomcat) with a new version of Cocoon, or a clean work/ directory, the first URL request entered caused compilation of the XSP page according to the case in the URL. E.g. the URL http://mamre/cocoon/mount/Ethnologue/checks/list-tables going through the Cocoon pipeline invoked .../Ethnologue/sources/count-rows.xsp which got compiled as org.apache.cocoon.www.mount.Ethnologue.sources Then if a later request URL used lowercase, http://mamre/cocoon/mount/ethnologue/checks/list-tables it invoked the same pipeline (because Cocoon in Windows is case- tolerant I guess), and everything still worked *except* for the XSP page. Apparently part of the XSP handler thought the compiled page already existed (or it would have compiled a second copy), but another part said "No, there's no compiled XSP page by that name." So the solution was, 1) Only access the data by the correct URL. 2) If somebody messes things up by making the first access with an incorrect URL, you have to shut down Tomcat, delete the work directory (or if you're smart maybe you can just delete a certain file), and restart Tomcat. Unresolved issue: Should this be considered a bug in Cocoon (and/or Tomcat)? I think so, because Cocoon in Windows is case-insensitive up to a point, but not completely. The inconsistency is what makes these problems sneaky. And even the XSP handling is inconsistent with regard to case; if it were truly case-sensitive, (I think) it should have given an error saying there was no such file as .../Ethnologue/sources/count-rows.xsp, instead of acting as if the reference to the xsp file was valid but then choking on its compiled class name. How it could bite: Besides the potential for confusing problems such as I experienced, this behavior leaves the door open for misinformed or malicious users (or weird browsers) to "break" a Cocoon system for everybody else, if they happen to be the "first one in" on any particular URL involving an XSP. They could, by accident or on purpose, use the "wrong" case, thus creating a compiled class package whose name was not the one expected; hence most subsequent users would encounter a mysterious error. Should I file a bug report? Does anybody have thoughts on whether this is a bug in Cocoon, Tomcat, or some component thereof? Lars --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
