commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: svn commit: r1209685 - /commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/
Date Sat, 03 Dec 2011 15:15:44 GMT
On 2011-12-03, Oliver Heger wrote:

>> Is configuration's dependency on Digester new or why have we started to
>> see this error just now?  You may want to upgrade to Digester 2.0 or 2.1
>> to start with (or even Digester3?) if it is new.  If it isn't then
>> obviously 2.x isn't compatible enough to 1.x for commons-configuration
>> and we could think about a different solution.

> Configuration now targets Java 1.5 so we try to incorporate generics
> in the API without breaking binary compatibility in the first
> draft.

OK, I see.  So as long as you target 1.4 Properties is good enough for
the Digester 2.x interface.

> What makes things a bit difficult to decide is the fact that the class
> affected in the Configuration code base (ConfigurationFactory) is
> actually deprecated, and it is the only one which requires the
> dependency to digester. Therefore there is not much motivation to do
> some major changes.

I can completely understand that and upgrading your Digester dependency
would only make sure you see the same kinds of errors Gump sees during
"normal" development.  Not sure it would help your users much.

>> We've had several bug reports against Ant when we assumed the system
>> properties would only hold string keys (or even values) and this
>> simply was not true in cases where Ant code was used embedded in a
>> larger application that was doing strange things.
>> java.util.Properties will not prevent you from putting objects into
>> it.  I assume a commons component is at a bigger risk of such
>> scenarios than an application like Ant.

>> Even if it takes a bit longer it may be cleaner to create a new Map that
>> contained a filtered view of only those properties that actually have
>> string keys.

> I also thought about the copying approach, but then hoped that for
> system properties it would be safe to rely on String keys.

You can always wait for the first bug report 8-)

Looking through MultiVariableExpander's code nothing in it really
requires the map to only contain string keys, it will just ignore all
others.  Even if the system properties contained non-String keys it is
very likely that nothing would break at all.


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

View raw message