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
configurations.
Oliver
thanks,
matt
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
