Steve Krulewitz wrote:
Hey folks --
I just spent some time debugging a problem (which turned out to be a
classpath issue, as always) and I just wanted to share my experience.
First of all, the way I develop with Cocoon is that I build the cocoon
jar, and jars for all the blocks I use, and I copy these jars plus all
the jars from lib/core and the blocks/*/lib dirs into my own webapp
development area.
I've been using the Sysdeo Tomcat Eclipse plugin with Cocoon for a few
days now and it has been working very well. I've been able to hot
update the actions and things I've been working on. However, when
hitting one particular pipeline that uses the JXTemplateGenerator, I
would get a blank page. View source, and nothing at all. No
exceptions on the console, nothing in the log files. The code running
in Tomcat separately worked fine, so it must have something to do with
the Sysdeo Tomcat environment.
After some stepping through code, it seems like there was a problem
getting an instance of the JXTemplateGenerator. It was very hard to
pinpoint because the invokeNodes methods in the
AbstractParentProcessingNode class just seems to silently swallow any
exception that is thrown by the node it is invoking:
try {
for (int i = 0; i < nodes.length; i++) {
if (nodes[i].invoke(env, context)) {
// Success
return true;
}
}
}
finally {
// No success
context.popMap();
}
return false;
After editing this code and catching the exception, I was able to
quickly tell that is was a NoClassDefFoundError, and that it had
something to do with Commons Loggings stuff. Turns out I didn't have
the commons-logging-1.0.3.jar in my classpath. The reason why I
didn't notice this before is because my Tomcat install has this jar in
its server/lib dir.
A few observations:
- Should commons-logging-1.0.3.jar be in lib/core rather than
lib/optional? In my case, the JXTemplateGenerator wouldn't run
without it.
- Should the invokeNodes() method in AbstractParentProcessingNode just
ignore the exception? Maybe it should be caught and logged?
The code above does not actively ignore the exception, even less
silently swallow anything. Errors are uncecked type exceptions in Java.
I don't presume you suggest this is the place you want to log any
throwable down the execution path? If I were to take a guess, this one
will end up in the catalina.log or something similar.
--
Unico
