cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Huttar" <lars_hut...@sil.org>
Subject RE: "The declared package does not match the expected package"?
Date Tue, 21 Oct 2003 21:22:17 GMT
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message