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.
Conclusion
----------
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
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
