Re: default value for evaluateProperties in ConfigResolver
Oki got it now. Yes, the projectstage postfixing lookup and the variable
replacement looks redundant at the first glimpse. But it really isn't.
The postfixing allows to have multiple configs for various scenarios already in
a properties file for example. The variable replacement is kind of the other
way around. You have a single key in your ConfigSource but you can tweak it
from outside.
Means you just add -Dmyapp.host.name=blablub.org and all the configs using
${myapp.host.name} will use this setting. With the previous version you would
need to explicitly set all 100++ config settings ;)
LieGrue,
strub
> On Friday, 15 April 2016, 13:48, John D. Ament wrote:
> > Apologies, I had a diff open and misread the change.
>
> My points about defaulting the behaviour and configurable key prefix/suffix
> remains. If it wasn't clear, my comment is that this should be the default
> behaviour of the other methods. Maybe not now for backwards compatibility,
> but at some point.
>
> John
>
>
> On Fri, Apr 15, 2016 at 7:11 AM Mark Struberg wrote:
>
>> It’s not duplicated. The variable logic is implemented exactly once right
>> now.
>>
>> LieGrue,
>> strub
>>
>>
>> > Am 15.04.2016 um 12:52 schrieb John D. Ament
> :
>> >
>> > Hi Mark,
>> >
>> > Thanks for bringing up this discussion!
>> >
>> > The way its implemented looks fine. When I first read your email, it
>> sounded like you were putting the onus on the config source to do the
>> variable expansion. This way allows you to cleanly have different sources
>> mixing variables together.
>> >
>> > Looking at the way its implemented, I would say that the non-expanding
>> methods should just overload and delegate into the expanding version.
>> Right now it looks like that logic is duplicated. What you're doing
> makes
>> sense for backwards compatibility but longer term I would imagine we want
>> filtering on by default.
>> >
>> > We should probably play a follow up ticket to this to allow you to
>> configure the prefix/suffix of your variables as well.
>> >
>> > John
>> >
>> > On Fri, Apr 15, 2016 at 6:31 AM Mark Struberg
>
>> wrote:
>> > Hi!
>> >
>> > I recently committed a feature to evaluate variables in config values.
>> >
>> >
>> > Basically having something like:
>> > -
>> > document.server.url=http://localhost:8081
>> > myapp.document.lists=${document.server.url}/docapp/list
>> > myapp.document.admin=${document.server.url}/docadmin/app
>> > -
>> > (atm adding this to our docs as well)
>> >
>> >
>> >
>> > In @ConfigProperty I enabled this feature by default.
>> >
>> > In ConfigResolver I just added a method 'evaluateVariables' in
>> TypedResolver and
>> > added new method to ConfigResolver itself:
>> >
>> > public static String getPropertyValue(String key, String defaultValue,
>> boolean evaluateVariables)
>> >
>> >
>> > How should the other getPropertyValue etc methods in ConfigReolver
>> behave?
>> >
>> > Thinking about it for a few days now I think it would be ok to enable
>> this feature for them as well.
>> >
>> > wdyt?
>> >
>> > LieGrue,
>> > strub
>>
>>
>
Re: default value for evaluateProperties in ConfigResolver
Apologies, I had a diff open and misread the change.
My points about defaulting the behaviour and configurable key prefix/suffix
remains. If it wasn't clear, my comment is that this should be the default
behaviour of the other methods. Maybe not now for backwards compatibility,
but at some point.
John
On Fri, Apr 15, 2016 at 7:11 AM Mark Struberg wrote:
> It’s not duplicated. The variable logic is implemented exactly once right
> now.
>
> LieGrue,
> strub
>
>
> > Am 15.04.2016 um 12:52 schrieb John D. Ament :
> >
> > Hi Mark,
> >
> > Thanks for bringing up this discussion!
> >
> > The way its implemented looks fine. When I first read your email, it
> sounded like you were putting the onus on the config source to do the
> variable expansion. This way allows you to cleanly have different sources
> mixing variables together.
> >
> > Looking at the way its implemented, I would say that the non-expanding
> methods should just overload and delegate into the expanding version.
> Right now it looks like that logic is duplicated. What you're doing makes
> sense for backwards compatibility but longer term I would imagine we want
> filtering on by default.
> >
> > We should probably play a follow up ticket to this to allow you to
> configure the prefix/suffix of your variables as well.
> >
> > John
> >
> > On Fri, Apr 15, 2016 at 6:31 AM Mark Struberg
> wrote:
> > Hi!
> >
> > I recently committed a feature to evaluate variables in config values.
> >
> >
> > Basically having something like:
> > -
> > document.server.url=http://localhost:8081
> > myapp.document.lists=${document.server.url}/docapp/list
> > myapp.document.admin=${document.server.url}/docadmin/app
> > -
> > (atm adding this to our docs as well)
> >
> >
> >
> > In @ConfigProperty I enabled this feature by default.
> >
> > In ConfigResolver I just added a method 'evaluateVariables' in
> TypedResolver and
> > added new method to ConfigResolver itself:
> >
> > public static String getPropertyValue(String key, String defaultValue,
> boolean evaluateVariables)
> >
> >
> > How should the other getPropertyValue etc methods in ConfigReolver
> behave?
> >
> > Thinking about it for a few days now I think it would be ok to enable
> this feature for them as well.
> >
> > wdyt?
> >
> > LieGrue,
> > strub
>
>
Re: default value for evaluateProperties in ConfigResolver
Sorry, wrong email :-)
Best regards
Kenneth
> On 15. apr. 2016, at 13.14, Kenneth Christensen
> wrote:
>
> Hun tager den om 5 min., hvis du ikke har taget den inden :-)
>
> /Kenneth
>
>> On 15. apr. 2016, at 13.11, Mark Struberg wrote:
>>
>> It’s not duplicated. The variable logic is implemented exactly once right
>> now.
>>
>> LieGrue,
>> strub
>>
>>
>>> Am 15.04.2016 um 12:52 schrieb John D. Ament :
>>>
>>> Hi Mark,
>>>
>>> Thanks for bringing up this discussion!
>>>
>>> The way its implemented looks fine. When I first read your email, it
>>> sounded like you were putting the onus on the config source to do the
>>> variable expansion. This way allows you to cleanly have different sources
>>> mixing variables together.
>>>
>>> Looking at the way its implemented, I would say that the non-expanding
>>> methods should just overload and delegate into the expanding version.
>>> Right now it looks like that logic is duplicated. What you're doing makes
>>> sense for backwards compatibility but longer term I would imagine we want
>>> filtering on by default.
>>>
>>> We should probably play a follow up ticket to this to allow you to
>>> configure the prefix/suffix of your variables as well.
>>>
>>> John
>>>
>>> On Fri, Apr 15, 2016 at 6:31 AM Mark Struberg
>>> wrote:
>>> Hi!
>>>
>>> I recently committed a feature to evaluate variables in config values.
>>>
>>>
>>> Basically having something like:
>>> -
>>> document.server.url=http://localhost:8081
>>> myapp.document.lists=${document.server.url}/docapp/list
>>> myapp.document.admin=${document.server.url}/docadmin/app
>>> -
>>> (atm adding this to our docs as well)
>>>
>>>
>>>
>>> In @ConfigProperty I enabled this feature by default.
>>>
>>> In ConfigResolver I just added a method 'evaluateVariables' in
>>> TypedResolver and
>>> added new method to ConfigResolver itself:
>>>
>>> public static String getPropertyValue(String key, String defaultValue,
>>> boolean evaluateVariables)
>>>
>>>
>>> How should the other getPropertyValue etc methods in ConfigReolver behave?
>>>
>>> Thinking about it for a few days now I think it would be ok to enable this
>>> feature for them as well.
>>>
>>> wdyt?
>>>
>>> LieGrue,
>>> strub
>>
>
> Med venlig hilsen
> e-branchekoden ApS
>
> Kenneth Christensen
> Partner
>
> ==
> Email fra e-branchekoden ApS
>
> e-branchekoden ApS
> Nordhavnsvej 1
> Postboks 94
> 3000 Helsingør
>
> Telefon: +45 24 66 13 10
> Mobil: +45 61 60 50 00
> Email: i...@e-branchekoden.dk
>
> http://www.e-branchekoden.dk
> ==
> e-branchekoden - din faglige sparringspartner
> ==
>
>
>
Med venlig hilsen
e-branchekoden ApS
Kenneth Christensen
Partner
==
Email fra e-branchekoden ApS
e-branchekoden ApS
Nordhavnsvej 1
Postboks 94
3000 Helsingør
Telefon: +45 24 66 13 10
Mobil: +45 61 60 50 00
Email: i...@e-branchekoden.dk
http://www.e-branchekoden.dk
==
e-branchekoden - din faglige sparringspartner
==
Re: default value for evaluateProperties in ConfigResolver
Hun tager den om 5 min., hvis du ikke har taget den inden :-)
/Kenneth
> On 15. apr. 2016, at 13.11, Mark Struberg wrote:
>
> It’s not duplicated. The variable logic is implemented exactly once right now.
>
> LieGrue,
> strub
>
>
>> Am 15.04.2016 um 12:52 schrieb John D. Ament :
>>
>> Hi Mark,
>>
>> Thanks for bringing up this discussion!
>>
>> The way its implemented looks fine. When I first read your email, it
>> sounded like you were putting the onus on the config source to do the
>> variable expansion. This way allows you to cleanly have different sources
>> mixing variables together.
>>
>> Looking at the way its implemented, I would say that the non-expanding
>> methods should just overload and delegate into the expanding version. Right
>> now it looks like that logic is duplicated. What you're doing makes sense
>> for backwards compatibility but longer term I would imagine we want
>> filtering on by default.
>>
>> We should probably play a follow up ticket to this to allow you to configure
>> the prefix/suffix of your variables as well.
>>
>> John
>>
>> On Fri, Apr 15, 2016 at 6:31 AM Mark Struberg
>> wrote:
>> Hi!
>>
>> I recently committed a feature to evaluate variables in config values.
>>
>>
>> Basically having something like:
>> -
>> document.server.url=http://localhost:8081
>> myapp.document.lists=${document.server.url}/docapp/list
>> myapp.document.admin=${document.server.url}/docadmin/app
>> -
>> (atm adding this to our docs as well)
>>
>>
>>
>> In @ConfigProperty I enabled this feature by default.
>>
>> In ConfigResolver I just added a method 'evaluateVariables' in TypedResolver
>> and
>> added new method to ConfigResolver itself:
>>
>> public static String getPropertyValue(String key, String defaultValue,
>> boolean evaluateVariables)
>>
>>
>> How should the other getPropertyValue etc methods in ConfigReolver behave?
>>
>> Thinking about it for a few days now I think it would be ok to enable this
>> feature for them as well.
>>
>> wdyt?
>>
>> LieGrue,
>> strub
>
Med venlig hilsen
e-branchekoden ApS
Kenneth Christensen
Partner
==
Email fra e-branchekoden ApS
e-branchekoden ApS
Nordhavnsvej 1
Postboks 94
3000 Helsingør
Telefon: +45 24 66 13 10
Mobil: +45 61 60 50 00
Email: i...@e-branchekoden.dk
http://www.e-branchekoden.dk
==
e-branchekoden - din faglige sparringspartner
==
Re: default value for evaluateProperties in ConfigResolver
It’s not duplicated. The variable logic is implemented exactly once right now.
LieGrue,
strub
> Am 15.04.2016 um 12:52 schrieb John D. Ament :
>
> Hi Mark,
>
> Thanks for bringing up this discussion!
>
> The way its implemented looks fine. When I first read your email, it sounded
> like you were putting the onus on the config source to do the variable
> expansion. This way allows you to cleanly have different sources mixing
> variables together.
>
> Looking at the way its implemented, I would say that the non-expanding
> methods should just overload and delegate into the expanding version. Right
> now it looks like that logic is duplicated. What you're doing makes sense
> for backwards compatibility but longer term I would imagine we want filtering
> on by default.
>
> We should probably play a follow up ticket to this to allow you to configure
> the prefix/suffix of your variables as well.
>
> John
>
> On Fri, Apr 15, 2016 at 6:31 AM Mark Struberg
> wrote:
> Hi!
>
> I recently committed a feature to evaluate variables in config values.
>
>
> Basically having something like:
> -
> document.server.url=http://localhost:8081
> myapp.document.lists=${document.server.url}/docapp/list
> myapp.document.admin=${document.server.url}/docadmin/app
> -
> (atm adding this to our docs as well)
>
>
>
> In @ConfigProperty I enabled this feature by default.
>
> In ConfigResolver I just added a method 'evaluateVariables' in TypedResolver
> and
> added new method to ConfigResolver itself:
>
> public static String getPropertyValue(String key, String defaultValue,
> boolean evaluateVariables)
>
>
> How should the other getPropertyValue etc methods in ConfigReolver behave?
>
> Thinking about it for a few days now I think it would be ok to enable this
> feature for them as well.
>
> wdyt?
>
> LieGrue,
> strub
Re: default value for evaluateProperties in ConfigResolver
Hi Mark,
Thanks for bringing up this discussion!
The way its implemented looks fine. When I first read your email, it
sounded like you were putting the onus on the config source to do the
variable expansion. This way allows you to cleanly have different sources
mixing variables together.
Looking at the way its implemented, I would say that the non-expanding
methods should just overload and delegate into the expanding version.
Right now it looks like that logic is duplicated. What you're doing makes
sense for backwards compatibility but longer term I would imagine we want
filtering on by default.
We should probably play a follow up ticket to this to allow you to
configure the prefix/suffix of your variables as well.
John
On Fri, Apr 15, 2016 at 6:31 AM Mark Struberg
wrote:
> Hi!
>
> I recently committed a feature to evaluate variables in config values.
>
>
> Basically having something like:
> -
> document.server.url=http://localhost:8081
> myapp.document.lists=${document.server.url}/docapp/list
> myapp.document.admin=${document.server.url}/docadmin/app
> -
> (atm adding this to our docs as well)
>
>
>
> In @ConfigProperty I enabled this feature by default.
>
> In ConfigResolver I just added a method 'evaluateVariables' in
> TypedResolver and
> added new method to ConfigResolver itself:
>
> public static String getPropertyValue(String key, String defaultValue,
> boolean evaluateVariables)
>
>
> How should the other getPropertyValue etc methods in ConfigReolver behave?
>
> Thinking about it for a few days now I think it would be ok to enable this
> feature for them as well.
>
> wdyt?
>
> LieGrue,
> strub
>
default value for evaluateProperties in ConfigResolver
Hi!
I recently committed a feature to evaluate variables in config values.
Basically having something like:
-
document.server.url=http://localhost:8081
myapp.document.lists=${document.server.url}/docapp/list
myapp.document.admin=${document.server.url}/docadmin/app
-
(atm adding this to our docs as well)
In @ConfigProperty I enabled this feature by default.
In ConfigResolver I just added a method 'evaluateVariables' in TypedResolver and
added new method to ConfigResolver itself:
public static String getPropertyValue(String key, String defaultValue, boolean
evaluateVariables)
How should the other getPropertyValue etc methods in ConfigReolver behave?
Thinking about it for a few days now I think it would be ok to enable this
feature for them as well.
wdyt?
LieGrue,
strub
