Ping!
Only two people commented on this proposal. Does this mean there's no
interest, or that I should elaborate more on it?
It seems to me that tracking the location of objects created from
configuration files and reporting locations in exceptions is a very
common need. Many projects have their own solution whereas other simply
ignore this problem, which makes life very difficult to the user when it
comes to correlating a Java exception with an error in a configuration file.
Having a common infrastructure (commons-location?) for this would allow
to ease the task of tracking locations and would bring cross-project
consistency in this area, just as commons already did in a number of
other areas.
So, what do you think?
Sylvain
Sylvain Wallez wrote:
Hi there,
A large number of applications are dealing with configuration files
(server.xml, struts-actions.xml, cocoon.xconf, etc) and
semi-interpreted languages (Cocoon's sitemap, template languages in
Tapestry, Cocoon and Velocity, etc).
A common problem with all these files is to report some meaningful
location information in the corresponding files when some problems
related to the information they contain occur (syntax error, invalid
class name, unkown component, etc). In such cases, the raw Java
exception is often of little use if it doesn't carry some location
information.
Tapestry has for long had its nice "line precise error reporting" (see
[1], section 2.14), and we needed something similar for Cocoon.
However Cocoon needed more than this as request handling involves
several levels of semi-interpreted languages, such as the sitemap,
XSLT or JavaScript.
So at Cocoon we have built a utility package that allow for location
stacktraces that complement regular Java stacktraces in exceptions.
The various levels of the Java call stack can also add their own
location information to the orginal exception without requiring
exception nesting, which leads to smaller, easier to understand
stracktraces.
I would like to propose this utility package for inclusion in Jakarta
Commons. This would allow for other projects to provide more easily
some meaningfull error reports, and, if successful, would make error
reporting globally more consistent when different products are used
together.
You can see this utility in action at [2], and browse the source code
in Cocoon's SVN [3]. It has no dependency except commons-lang where
IMHO it would fit nicely.
What do you think? Is it of interest to the commons project?
Thanks,
Sylvain
[1] http://jakarta.apache.org/tapestry/3.0.3/faq.html
[2] http://www.anyware-tech.com/blogs/sylvain/archives/000210.html
[3]
http://svn.apache.org/repos/asf/cocoon/trunk/src/java/org/apache/cocoon/util/location/
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
