tamaya-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anatole Tresch (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (TAMAYA-378) Clarify Property Key Resolution on Injection
Date Tue, 14 May 2019 15:04:00 GMT

     [ 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)

Mime
View raw message