tamaya-functions MappedConfiguration behaves oddly

[Thomas Liebetraut <th...@tommie-lie.de>]

Hi list,

we are using tamaya-functions to strip configuration keys for individual
modules.
The schema works as follows:

  module.submodule1.value0
  module.submodule1.subsubmodule1.value1
  module.submodule1.subsubmodule2.value2
  module.submodule2.subsubmodule3.value3

There are separate Java classes for module, submodule1, submodule2, and
the three subsubmodules. When module gets the configuration, it
configures itself and tries to configure submodule1 and submodule2. In
order to configure submodule1, it strip "module.submodule1." from the
config and passes it to the configure method of subdmodule1. submodule1
sees the "virtual" configuration as:

  value0
  subsubmodule1.value1
  subsubmodule2.value2

The configuration logic of submodule1 does not need to know its position
in the configuration hierarchy but only know "I have a config value with
key 'value0' and I have two subsubmodules.".

So far, so good, and this is what tamaya-functions'
section(stripKeys=true) function should do (I think).

The MappedConfiguration in tamaya-functions is somewhat useless in this
respect, though. The KeyMapper that is created by
ConfigurationFunctions.section() removes the given prefix from the key,
i.e. "module.submodule1.value0" becomes "value0".

MappedConfiguration.getProperties() creates a new Hashmap and for every
key in the base configuration, it adds keyMapper.addKey(originalKey).
So, the result of getProperties() will return a map with all the
prefixes in the keys removed.

MappedConfiguration.get(), on the other hand, takes the key argument,
calls keyMapper.mapKey() on it, thus removing the prefix, and then
passes it to the base configuration. This way, the MappedConfiguration
looks wether "value0" is in the base configuration. Furthermore, I have
to pass "module.submodule1.value0" to MappedConfiguration.get() in order
to look for "value0" in the base configuration.

My assumption would have been that MappedConfiguration.get(s) is
equivalent to MappedConfiguration.getProperties().get(s).

There are some things wrong in the way MappedConfiguration is designed
right now. The KeyMapper interface only has one method: mapKey(). As key
mapping is not always reversible (think of a key mapper that converts
all chars to uppercase), one function cannot be used for both,
converting base configuration keys to mapped keys and to convert mapped
keys from the user to base configuration keys. This is what the current
MappedConfiguration code tries and of course it fails at doing so.

Because we definitely need this feature (and we are currently using a
very bad workaround), I am willing to contribute to this module and make
it more useful. However, I want to be sure that I do it like it was
indented to be used and that you as maintainers and I as contributor
have agreed on an interface.

Just calling getProperties() every time get() is called will a) cause
the HashMap to always be regenerated (which is probably a good thing in
case the configuration changes at runtime) and b) make it necessary to
re-implement the type conversion logic again in MappedConfiguration.


Currently I don't have a really good solution to solve the problem but
that may also be due to my head still not working properly after I was
sick the past few days.
I hope I made the problem clear and I am open to any suggestion on a
proper solution. I will also try to figure something out once I can
think straight again.
I will also try to attent the hangout today.


Cheers,
Thomas