commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <>
Subject Re: [proposal] Location utilities
Date Sun, 18 Sep 2005 11:01:10 GMT
My main concern would be whether framework providers would be convinced 
to use it. Does it provide enough benefit to a framework provider over 
just writing the code yourself? Would existing frameworks switch to it?

Also, [location] made me think of locations in the world, so maybe 
commons-exception would be clearer.


Sylvain Wallez wrote:
> 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]
>> [2]
>> [3] 


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

View raw message