[
https://issues.apache.org/jira/browse/TAMAYA-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16753622#comment-16753622
]
Anatole Tresch commented on TAMAYA-378:
---------------------------------------
Thank you for your inputs. I try to clarify my thoughts and I am looking
forward to see what you think:
[~ajs6f] Designing the _KeyResolution_ as a interface/class introduces
additional complexity (and an additional API level). The question for me is
then: do we need that? Even rememorizing the worst use cases I have ever seen I
would argue no. So what kind of use cases have you in mind that are not covered
as of now?
[~wlieurance] The idea for applying the resolution only on the main key were
the following:
* In most cases you will NOT use fallback keys, you only use the _key_ feature.
* Main use case for fallback keys IMO is supporting _deprecated_ keys. These
keys may, or may not share the same root area (typically I would argue they DO
NOT share the same root area in most cases). Let me do an example:
{code:java}
public class MyServer{
@config(key=myapplication.port, fallbackKeys={"server.port"},
defaultValue="8088",
keyResolution=KeyResolution.ABSOLUTE)
int port;
@Config
String serverName;
...
}{code}
In this example I want to be able to support the default Springboot
configuration location as a fallback. So the config keys looked up for _port_
are:
{code:java}
myapplication.port, server.port{code}
But things get more complicated, when we use the _@ConfigArea_ annotation:
{code:java}
@ConfigArea("myapplication")
public class MyServer{
@config(key=port, fallbackKeys={"server.port"}, defaultValue="8088")
int port;
@Config
String serverName;
...
}{code}
If we would apply the same _KeyResolution_ for both _key_ and _fallbackKeys_
this would result in the following lookup chain (the default resolution is
_AUTO_):
{code:java}
myapplication.port, mayapplication.server.port{code}
This is not what we wanted! Even worse, we can only escape by defining the
resolution as _ABSOLUTE._ As a consequence we lose the possibility defining the
_port_ parameter as a relative area parameter. So we would have to add the
common area in the key definition again.
{code:java}
@ConfigArea("myapplication")
public class MyServer{
@config(key=myapplication.port, fallbackKeys={"server.port"},
defaultValue="8088",
keyResolution=KeyResolution.ABSOLUTE)
int port;
@Config
String serverName;
...
}{code}
By applying the _KeyResolution_ only on the main key we dont have to change
anything on the existing configuration, we simply add the additional fallback
keys and we are done.
> 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)
