[
https://issues.apache.org/jira/browse/TAMAYA-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16749735#comment-16749735
]
William Lieurance commented on TAMAYA-378:
------------------------------------------
I agree that a Class for KeyResolution makes it more extensible, and matches
better with what we do for ConfigValueEvaluator and our Converters and such.
I'm also confused why "key" would be treated so differently from "fallbackKey",
especially around prefixes in RELATIVE_FQN. My gut tells me that a
"fallbackKey" would be subject to the same prefixing. The use case I can see
for this is a transition from one config key name to another, which would make
me value consistency in the way that the keys are looked up.
> 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
> Remaining Estimate: 4h
>
> 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)
