commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Bourg <ebo...@micropole-univers.com>
Subject Re: [configuration] Roadmap
Date Thu, 04 Mar 2004 16:39:53 GMT
Jörg Schaible wrote:

> remove here also the dependency to StringUtils (just used to handle an empty String).
Basic idea - if I just use properties and DOM, I would like to have the least number of dependencies
as possible. If other lang functionality would have been used here, no problem - but *not*
for an empty String test ...

[configuration] also use the StringEscapeUtils and BooleanUtils from 
[lang], as well as the NestableException for the ConfigurationException. 
I don't think it's wise to remove this dependency, [lang] is so 
ubiquitous it shouldn't be an issue to keep it.


>>- DOM4J dependency removal
> 
> Working on this. I understand correctly, that this just means support of DOM, but no
deprecation of JDOM ?

Well if there is no benefit in using DOM4J instead of javax.xml I would 
drop the dependency. I'm not familiar with DOM4J so forgive me if I'm 
saying an heresy ;)


>>- system properties interpolation (Bug 26066)
> 
> Can we introcuce a basic support for 1.0 (I will need this anyway)? I am thinking of
a SystemPropertyConfiguration as singleton. Does that make sense? You could use it in a composition.
Or do you think of an implicit support in interpolateHelper ?

A system configuration can already be obtained through the 
ConfigurationConverter class with:

ConfigurationConverter.getConfiguration(System.getProperties())

The only issue is that it provides a copy of the Properties, I'm 
preparing a patch that returns a wrapper instead.

Such a configuration combined with a CompositeConfiguration could solve 
Bug 26066. This would require a <system> element handled by the 
ConfigurationFactory.

Initially I was thinking at supporting this directly in interpolateHelper.

Emmanuel Bourg


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