commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [proposal] Location utilities
Date Sun, 18 Sep 2005 09:03:06 GMT

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 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]
> [2]
> [3] 

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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message