Anatole Tresch created TAMAYA-378:
-------------------------------------
Summary: Clarify Property Key Resolution on Injection
Key: TAMAYA-378
URL: https://issues.apache.org/jira/browse/TAMAYA-378
Project: Tamaya
Issue Type: Improvement
Components: Extensions
Affects Versions: 0.3-incubating
Reporter: Anatole Tresch
Assignee: Anatole Tresch
Fix For: 0.4-incubating
h2. Current Situation
Currently key resolution is very complex and leads to many different keys
potentially being looked up. Given the following class:
{code:java}
package a.b.c;
public class Injected{
@Config("myProp", "myFallbackProp")
private String property;
}
{code}
Would evaluate to the following key lookup chain:
{code:java}
a.b.c.Injected.myProp
a.b.c.Injected.myFallbackProp
Injected.myProp
Injected.myFallbackProp
myProp
myFallbackProp{code}
h2. Proposal
This is weird to the user, so the proposal is to
# Separate the main from the fallback keys
# Allow to define how to combine the (field)property key, with the class key.
Therefore the _@Config_ annotation should be adapted as follows:
{code:java}
public @interface Config {
String UNCONFIGURED_VALUE = ...;
String key() default "";
KeyResolution keyResolution() default KeyResolution.AUTO;
String[] alternateKeys() default {};
String defaultValue() default UNCONFIGURED_VALUE;
boolean required() default true;
}
{code}
Herebythe enum type _KeyResolution_ defines how the property key(s) are
evaluated:
* *AUTO*: This is the default key resolution strateg. The targeting key is
evaluated as follows:
** The containing class _does not_ have a @_ConfigSection_ annotation and the
field/method does not have a _@Config_ annotation:
the main key equals to
_Owning.class.getSimpleName() + '.' + propertyKey_.
{{This equals to }}_RELATIVE_SIMPLE_.
** The containing class *does not have* a _@ConfigArea_ annotation:
the main key equals to
_propertyKey_.
This equals to _ABSOLUTE_
** The containing class *does* have a _@ConfigArea_ annotation:
the main key equals to
_sectionAnnotation.getValue() + '.' + propertyKe_y.
* *RELATIVE_SIMPLE:* The targeting key is evaluated to
_Owner.class.getSimpleName() + '.' + * propertyKey_
* *RELATIVE_FQN*: ** The targeting key is evaluated to
_Owner.class.getName() + '.' + * propertyKey_
* *ABSOLUTE*: The targeting key is evaluated to _propertyKey._
Hereby this resolution policy only applies to the main property key, modelled
by key()_,_ whereas fallback keys always are considered as _ABSOLUTE_ keys.
h2. Example
Given the following class:
{code:java}
package a.b.c;
public class Injected{
@Config(key="myProp", fallbackKeys={"myFallbackProp"})
private String property;
}
{code}
Would evaluate to the following key lookup chain:
{code:java}
Injected.myProp
myFallbackProp{code}
Using _KeyResolution.ABSOLUTE_ the keys would be:
{code:java}
myProp
myFallbackProp{code}
Using _KeyResolution.RELATIVE_FQN_ the keys would be:
{code:java}
a.b.c.Injected.myProp
myFallbackProp{code}
This drastically reduces the keyset and makes the resolution more explicit and
less magic IMO.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
