cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Cocoon stack traces
Date Mon, 01 Aug 2005 13:10:44 GMT
Hi all,

I have refactored the error handling stuff to have Cocoon stack traces, 
i.e. a trace of the involved components and the corresponding locations 
in the call stack.

For example, we can track nested JXTG macro calls, flowscript function 
calls, pipeline locations, mounted sitemaps, etc. More locations will be 
added in the future.

This refactoring is based on a few new features:

Location management
The new org.apache.cocoon.util.location package defines the Location 
class (a URI, line and column numbers) and a Locatable interface for 
objects that have a Location.

The LocatorAsAttributesPipe is a SAX filter that registers parser 
location information as attributes on elements. This used by CForms to 
parse form definitions and bindings, thus removing the dependency on 
some Xerces internal APIs.

The LocatedException and LocatedRuntimeException classes are exceptions 
that implement Locatable and therefore hold a Location. 
ProcessingException now extends LocatedException so that we're able to 
attach a location to a processing error.

The class org.apache.cocoon.util.ExceptionUtils allows to get the 
location of LocatedException and some other well-known exception classes 
that hold a location (e.g. SAXParseException).

Exception management
A Cocoon stacktrace is defined by all exceptions in an exception chain 
that have a location. To add a particular statement to a Cocoon 
stacktrace, it is therefore necessary to provide this location 
information. This requires that we identify those places that we want to 
see in stacktraces, and make sure to catch exceptions and rethrow them 
wrapped in a LocatedException.

I did this already for a few strategic places: flowscript calls, 
serialize statemements (that trigger execution of a pipeline) and 
mounts. The JTXG was already doing this wrapping using SAXParseException 
in macro calls.

Exception display and log
The NotifyingGenerator and the associated stuff is... ahem... very 
complicated for something simple, and modifying it to handle a set of 
locations rather than a single one didn't seem obvious.

I therefore wrote a new ExceptionGenerator that directly dumps as XML 
the Throwable catched by <map:handle-errors>, including all the needed 
location and stacktrace information. You can see it in action when an 
error occurs: a new "Cocoon stacktrace" section is now displayed along 
with the not-so-friendly Java stacktraces.

And since these error pages should not be used in production, I also 
made sure that a LocatedException correctly prints the location in 
printStackTrace() so that we have the same information in the log files.

The Cocoon stacktrace gives some very valuable information about what 
problem happened, and more importantly where it happened. We now need to 
progressively add location information to important places in the code 
to make these Cocoon stacktraces more and more useful!

Tell me what you think!


Sylvain Wallez                        Anyware Technologies
Apache Software Foundation Member     Research & Technology Director

View raw message