OK. I figured out how to use the matches attribute and was able to
verify that it doesn't throw ClassNotFoundExceptions all the time. I'll
do a little load testing next to see what kind of difference it makes on
throughput.
Ralph Goers wrote:
We took some thread dumps of our product when it was running
normally. It was interesting in that we still saw in almost every
stack trace the portal calling castor which was in the class loader
throwing a ClassNotFoundException. I then stepped through the sample
site and have discovered that when
<bind-xml auto-naming="deriveByClass">
is used, Castor starts making up names and trying to load them. For
example, when a named item is specified inside a composite layout
castor takes
org.apache.cocoon.portal.layout.impl.CompositeLayoutImpl
strips off CompositeLayoutImpl and replaces it with NamedItem. It
then tries to load that class and gets a ClassNotFoundException
because NamedItem isn't in the same package. It eventually uses the
correct class name. This makes login extremely slow as every item is
throwing an exception. And, I expect, when the resource pool is
exceeded the class loader is completely overstressed and the system
comes to a grinding halt. It doesn't actually stop, but from then on
it moves so slowly that it might as well be dead.
The code in Castor suggests using the matches attribute to bypass
this. Unfortunately, there are no examples to be found on how matches
could solve this problem.
So the bottom line is, unless all your classes are in the same package
do not use deriveByClass. Or don't use Castor.
Ralph
