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.

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.

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.


thanks,


matt

Reply via email to