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 20:55:03 GMT
Stephen Colebourne wrote:

> 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?

As I said in my answer to James, frameworks that already have such a 
feature may be reluctant to switching to this stuff because of code 
compatibility problems. But there are a number of other projects where 
external files don't have as much importance as they have in 
Hivemind/Tapestry and Cocoon where the problem is simply ignored or 
poorly considered because it is not vital to the project.

This is one of the main purposes of this proposal: provide an easy 
solution to this problem, so that ignoring it is no more an option. The 
other purpose being that, through and increased cross-project 
consistency, it's easier to deal with external files handled by 
third-party libraries that use this common location stuff, thus avoiding 
(or at least limiting) the need to parse error messages to rebuild the 
location information.

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

Hmm... it's not only about exceptions, but more about locations in files 
(config, template, properties, whatever), and attaching these locations 
to objects that were created from these files. Locations can then be 
used in log messages, exceptions, and why not specialized debuggers (I'm 
about to write one for Cocoon).

So, what about "object-location" or the shorter "objloc"?


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

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

View raw message