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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
