Hi all,
I used to use my own Configuration package, as well as my own logging and
command-line arguments handling libraries. Recently I switched to log4j
and jakarta-commons-cli. I was planing to migrate my current projects to
jakarta-commons-configuration when I discovered some differences in the
way defaults and subsets are handled.
* First, the defaults. Why is it a protected field in BaseConfiguration ?
I mean why don't you have the following in the Configuration interface:
Configuration.setDefaults(Configuration defaults)
So a Configuration object (here defaults) could act as the "fallback" for
another one.
At least we could have a constructor for BaseConfiguration with a defaults
parameter (just like PropertiesConfiguration).
* Second, the subsets. What you get when you call the subset() method is
a COPY of the keys and their respective values from a given configuration.
Which means changing the value of any of the keys in the source
configuration will not be visible in the target one. While I understand
this behaviour can be of some use, I think there should be a way to get a
subset that stays "connected" to its source. Think of it as a proxy
configuration (ProxyConfiguration ?) that just pass the Configuration
interface method calls prefixed by its own prefix.
For me, there are (at least) three ways of getting a configuration from
another:
- Getting a copy of the source configuration (possibly with some key
pattern rule to copy just a subset of the keys). Changes in the sources
are not passed to the target.
- Getting a relative view of some source configuration (what is spoken of
above). The target configuration owns a prefix it adds to each key before
passing the method call to the source. Changes on the source are visible
by the target. Moreover changes on the target are in fact commited on the
source.
- Getting a relative copy of some source configuration. Which is
basically the copy of a relative view (what is currently implemented is
jakarta-commons-configuration).
I will just give an example of what can be achieved by the two features I
speak of in this mail. This way, if anybody knows a way to do it with the
current commons-configuration package, please let me know.
I am coding a network simulator. I have a superclass Network and different
implementations (classes that extends it): GridNetwork, HypercubeNetwork,
TreeNetwork... Each time I experiment some settings, I want to do it for
all different networks. So I restart the simulation choosing a different
netwrok implementation. Each implementation has its own configuration keys
(depth for trees, height/width for grids, size for hypercube...) but they
all share some parameters (link latency for example).
I also have a command-line interface to change properties at run-time.
So the configuration for Network would be a subset of the global
configuration with the "mypackage.Network" prefix. And the configuration
for GridNetwork would be a subset of the global configuration with the
"mypackage.GridNetwork" prefix, but which falls back to the Network
configuration for common keys that are not duplicated in the GridNetwork
configuration.
If I type the following at run-time:
set mypackage.Network.link-latency=5
It will change the link latency of the current implementation, say
GridNetwork. Link latency is checked by a Network implementation just by
getting the "link-latency" value (no prefix needed).
Hope it sounds clear enough. If not, please ask questions because I would
really appreciate to find a solution to my problem. This way I could
switch to commons-configuration and give up maintaining my own library.
Also, I would help to code the changes needed if they were to be adopted.
The only thing I cannot do (yet) is provide unit tests. But sooner or
later I will need to learn JUnit, so maybe this is time for it.
Regards,
Herve
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
