Sorry, wrong email :-) Best regards
Kenneth > On 15. apr. 2016, at 13.14, Kenneth Christensen <k...@e-branchekoden.com> > wrote: > > Hun tager den om 5 min., hvis du ikke har taget den inden :-) > > /Kenneth > >> On 15. apr. 2016, at 13.11, Mark Struberg <strub...@yahoo.de.INVALID> 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 <johndam...@apache.org>: >>> >>> 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 <strub...@yahoo.de.invalid> >>> 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 ======================================================
