[configuration]Resolving constants

[Oliver Heger <Ol...@t-online.de>]

Hi,

I had an idea for another small enhancement and want to ask if you find 
it useful.

I had sometimes the problem that I had to store a value in a 
configuration file that was defined as a constant in a Java class. E.g. 
let there be the following declaration in a class:

public static final int ANSWER_TO_ALL = 42;

It would now be nice (for the sake of consistency and readability) to 
write something in a configuration file like

myProperty = ${mypackage.MyClass.ANSWER_TO_ALL}

instead of a more cryptic myProperty = 42. I think, this is quite easy 
to implement. I would modify AbstractConfiguration.addProperty() to call 
a new resolve() method. This resolve() Method would check for string 
properties if they match a certain pattern (like the ant notation 
${...}) and if yes, try to fetch the constant value via reflection. Do 
you think this feature is worth to be added to configuration?

What are you planning to change to make configuration ready for the 
first release? I was thinking about this, too, and came up with two 
points that could be improved:

1. Exception handling: There are some methods (especially for loading 
configuration files) that have a throws Exception clause. This is quite 
ugly in my opinion and should be replaced, maybe by a new 
ConfigurationException. Though I am not sure about the best strategy. 
For server sided applications, when an exception during loading 
configuration files usually means a deloyment problem, throwing a 
runtime exception might be sufficient. But other use cases will have 
probably other requirements.

2. Sometimes inconsistent interfaces: This refers to some of the 
concrete subclasses of AbstractConfiguration. Some of them have load() 
methods with different signatures, some have save() methods, others 
don't. It would be nice to have a common pattern here, but I don't 
consider this very critical.

Oli



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org