I upgraded Xalan to 2.5.1 and Xerces to 2.4.0 in the Cocoon 2.0 CVS, so they should be in the next Cocoon 2.0.x release - I guess the 5 comes after the 4 ;-)
Joerg
Bruce Robertson wrote:
I've found that under JDK 1.4 my Cocoon 2.0.4 based project (http://heml.mta.ca) tended to spawn a huge number of open files and after a couple of days of service would: a) crash with a 'too many open files' jvm error
b) start throwing 'unknown xpath error's in unlikely places.
By checking with the unix 'lsof' utility, I found that the problem was with files accessed through xsl's document() function. (This isn't a function you should get into the habit of using with Cocoon, but at one point I wanted my xslts to work outside Cocoon, too. I'll probably change things when I rewrite that section.) Those files never seemed to get properly closed, except with garbage collection.
The lastest version of Xalan has a fix for this bug
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4858
which directly relates to point b) above. So I replaced the stock Xalan in
Cocoon 2.0.4 with Xalan 2.5 and the necessary Xerces. And the result was ...
some of my xslt threw new errors :-( In particular, it looks like the xpath
parsing is more strict, which is probably a good thing. I fixed those, and, hey,
it works. I tried hammering the server with requests, and no failure so far.
A happy outcome of this is that the part of my code using document() calls, which had been unreasonably slow, now runs much faster. This is not a measured result, but I'm certain it's true.
The upshot is that people who, against advice, use document() in their Cocoon-processed xslt should look into swapping in the Xalan 2.5 jar.
Yrs,
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
