[ https://issues.apache.org/jira/browse/TAMAYA-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Anatole Tresch resolved TAMAYA-378. ----------------------------------- Resolution: Fixed > 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 > Priority: Major > Fix For: 0.4-incubating > > Original Estimate: 4h > Time Spent: 1h 10m > Remaining Estimate: 2h 50m > > 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)