[jira] [Created] (TAMAYA-378) Clarify Property Key Resolution on Injection

["Anatole Tresch (JIRA)" <ji...@apache.org>]

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)