commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [proposal] Location utilities
Date Sun, 18 Sep 2005 09:03:06 GMT
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message