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

["William Lieurance (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TAMAYA-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16758094#comment-16758094 ] 

William Lieurance commented on TAMAYA-378:
------------------------------------------

Hey Anatole,

 

I completely agree that this would be used for deprecated keys.  I'm a little worried about lookup changes that would happen *without* the @ConfigArea annotation being added.  Let's take your example from a different direction.

I start with my config in "MyServer.server.port=blah" which makes this work correctly:
{code:java}
public class MyServer{

  @config(key="server.port", defaultValue="8088")
  int port;

  @Config
  String serverName;
  ...
}{code}
That feels like a pretty normal use case to me. Then, we intend in the future to move to "MyServer.myapplication.port=blah", and deprecate "MyServer.server.port"
{code:java}
public class MyServer{

  @config(key="myapplication.port", fallbackKeys={"server.port"}, defaultValue="8088")
  int port;

  @Config
  String serverName;
  ...
}
{code}
Suddenly, though, my code stops working. Turns out that fallbackKeys don't get prefixed with the classname, despite me never changing any part of the class, or really even thinking about class refactoring. This feels to me like both the more common deprecation use case and the smaller one (not deprecating at the same time as also refactoring to include @ConfigArea).

Does that make sense to you?  I think we're both trying to reduce the amount of surprise that users experience with Tamaya.

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