commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject Re: [configuration] A couple potential patches
Date Fri, 20 Jan 2012 20:10:01 GMT
Hello Matt,

this is interesting stuff! Comments inline...

Am 20.01.2012 17:19, schrieb Matt Hoffman:
> I'm glad to see commons configuration is alive again!
> I made a couple of changes to trunk locally, for my own use; are any of
> these potentially interesting for the wider community?  If so, I can
> package up a patch and submit it via JIRA. Since they're currently
> intertwined, I figured I would ask before splitting them out and making
> patches:
> 1.) Created interfaces "AggregateConfiguration" and
> "WriteableAggregateConfiguration" that the two aggregate configurations
> (CombinedConfiguration and CompositeConfiguration) can share. They have
> basic methods like "getConfigurations()", "getSource(String key)",
> "getConfiguration(int index)", "addConfiguration(Configuration config)" and
> so on.  The two classes had several identical or very similar methods
> already, I just made an interface for them.

I like this idea. It seems useful to have a common interface for these 
configuration classes. So a Jira ticket with a patch would be appreciated.

> 2.) added "getName()" to configuration.  This is by default the filename
> for a file-based configuration, or a string like "CombinedConfiguration of
> { configurations.getName }" for a combinedConfiguration, etc.  Not terribly
> important, but nice to have. I wanted to be able to answer "what
> configuration file is this property coming from?" and that made it easier.

Unfortunately, adding a method to an interface is also a breaking change 
as it causes custom implementations to crash. So this change would have 
to wait for version 2.0.

> 3.) Split the "Configuration" interface in two:  "Configuration" and
> "WriteableConfiguration".  That could have been named
> "MutableConfiguration", instead.  In my application, I don't want users of
> Configuration to be able to modify the configuration at any old time.  So I
> just split out the set... and add... properties into a separate interface
> -- WriteableConfiguration -- that extends Configuration.  So if you send
> around a Configuration object, the user cannot change properties. If you
> hand them a WriteableConfiguration object, they can.  Having the mutability
> characteristics being explicit seemed like a safer option there, but that
> is a breaking change for a lot of users -- I removed methods from the
> Configuration interface, after all -- so that's not a change you could put
> in before 2.0, if you were interested at all.

Unmodifiable configurations are on our to-do list. A split of the 
Configuration interface is one way to achieve this. However, a malicious 
client could still try to cast a Configuration object to a 
WritableConfiguration and then manipulate it. An alternative would be to 
create a wrapper around the Configuration object which throws 
UnsupportedOperationException for manipulating methods. This is similar 
to the way the Java Collection framework implements this feature. Not 
sure which way to go. But for version 2.0 we should in any case consider 
to have two Configuration interfaces for read only and mutable 


> thanks,
> matt

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

View raw message