Re: [text] Adapt the Log4j 2 Interpolator to [text]
On Tue, Feb 13, 2018 at 11:06 AM, Pascal Schumacher < pascalschumac...@gmx.net> wrote: > Am 12.02.2018 um 21:53 schrieb Gary Gregory: > >> On Mon, Feb 12, 2018 at 12:53 PM, Gary Gregory >> wrote: >> >> On Mon, Feb 12, 2018 at 12:30 PM, Pascal Schumacher < >>> pascalschumac...@gmx.net> wrote: >>> >>> please revert "Update actual Checkstyle from 6.19 to 8.8.", as Checkstyle 7+ requries Java 8+. Done. >>> >> > Thanks! > >> and please fix the findbugs violation: [INFO] --- findbugs-maven-plugin:3.0.5:check(default-cli)@ commons-text--- [INFO] BugInstance size is 1 [INFO] Error size is 0 [INFO] Total bugs: 1 [INFO] org.apache.commons.text.StringTokenizer.clone() does not call super.clone() [org.apache.commons.text.StringTokenizer] At StringTokenizer.java:[lines 1138-1140] CN_IDIOM_NO_SUPER_CALL But super.clone() is called, from another method... >>> >>> And findbugs does not complain about the same code in StrTokenizer. What? >> > > For StrTokenizer there is an exclusion in fb-excludes.xml. Thank you for the pointer. I updated the FB exclusion file to do the same for org.apache.commons.text.StringTokenizer. Gary > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [text] Adapt the Log4j 2 Interpolator to [text]
Am 12.02.2018 um 21:53 schrieb Gary Gregory: On Mon, Feb 12, 2018 at 12:53 PM, Gary Gregory wrote: On Mon, Feb 12, 2018 at 12:30 PM, Pascal Schumacher < pascalschumac...@gmx.net> wrote: please revert "Update actual Checkstyle from 6.19 to 8.8.", as Checkstyle 7+ requries Java 8+. Done. Thanks! and please fix the findbugs violation: [INFO] --- findbugs-maven-plugin:3.0.5:check(default-cli)@ commons-text--- [INFO] BugInstance size is 1 [INFO] Error size is 0 [INFO] Total bugs: 1 [INFO] org.apache.commons.text.StringTokenizer.clone() does not call super.clone() [org.apache.commons.text.StringTokenizer] At StringTokenizer.java:[lines 1138-1140] CN_IDIOM_NO_SUPER_CALL But super.clone() is called, from another method... And findbugs does not complain about the same code in StrTokenizer. What? For StrTokenizer there is an exclusion in fb-excludes.xml. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [text] Adapt the Log4j 2 Interpolator to [text]
On Mon, Feb 12, 2018 at 12:53 PM, Gary Gregory wrote: > > > On Mon, Feb 12, 2018 at 12:30 PM, Pascal Schumacher < > pascalschumac...@gmx.net> wrote: > >> Am 12.02.2018 um 18:52 schrieb Gary Gregory: >> >>> I agree 100% and will proceed. I thought about it overnight and it does >>> not >>> make sense to leave a mix of abstract classes and interfaces in >>> StrSubstitutor. >>> >> >> +1, but >> >> please revert "Update actual Checkstyle from 6.19 to 8.8.", as Checkstyle >> 7+ requries Java 8+. >> > > Done. > > >> >> and please fix the findbugs violation: >> >> [INFO] --- findbugs-maven-plugin:3.0.5:check(default-cli)@ >> commons-text--- >> [INFO] BugInstance size is 1 >> [INFO] Error size is 0 >> [INFO] Total bugs: 1 >> [INFO] org.apache.commons.text.StringTokenizer.clone() does not call >> super.clone() [org.apache.commons.text.StringTokenizer] At >> StringTokenizer.java:[lines 1138-1140] CN_IDIOM_NO_SUPER_CALL >> > > But super.clone() is called, from another method... > And findbugs does not complain about the same code in StrTokenizer. What? Gary > > Gary > > >> >> to fix the travis build. >> >> Thanks, >> Pascal >> > >
Re: [text] Adapt the Log4j 2 Interpolator to [text]
On Mon, Feb 12, 2018 at 12:30 PM, Pascal Schumacher < pascalschumac...@gmx.net> wrote: > Am 12.02.2018 um 18:52 schrieb Gary Gregory: > >> I agree 100% and will proceed. I thought about it overnight and it does >> not >> make sense to leave a mix of abstract classes and interfaces in >> StrSubstitutor. >> > > +1, but > > please revert "Update actual Checkstyle from 6.19 to 8.8.", as Checkstyle > 7+ requries Java 8+. > Done. > > and please fix the findbugs violation: > > [INFO] --- findbugs-maven-plugin:3.0.5:check(default-cli)@ commons-text--- > [INFO] BugInstance size is 1 > [INFO] Error size is 0 > [INFO] Total bugs: 1 > [INFO] org.apache.commons.text.StringTokenizer.clone() does not call > super.clone() [org.apache.commons.text.StringTokenizer] At > StringTokenizer.java:[lines 1138-1140] CN_IDIOM_NO_SUPER_CALL > But super.clone() is called, from another method... Gary > > to fix the travis build. > > Thanks, > Pascal >
Re: [text] Adapt the Log4j 2 Interpolator to [text]
Am 12.02.2018 um 18:52 schrieb Gary Gregory: I agree 100% and will proceed. I thought about it overnight and it does not make sense to leave a mix of abstract classes and interfaces in StrSubstitutor. +1, but please revert "Update actual Checkstyle from 6.19 to 8.8.", as Checkstyle 7+ requries Java 8+. and please fix the findbugs violation: [INFO] --- findbugs-maven-plugin:3.0.5:check(default-cli)@ commons-text--- [INFO] BugInstance size is 1 [INFO] Error size is 0 [INFO] Total bugs: 1 [INFO] org.apache.commons.text.StringTokenizer.clone() does not call super.clone() [org.apache.commons.text.StringTokenizer] At StringTokenizer.java:[lines 1138-1140] CN_IDIOM_NO_SUPER_CALL to fix the travis build. Thanks, Pascal
Re: [text] Adapt the Log4j 2 Interpolator to [text]
On Sun, Feb 11, 2018 at 8:12 PM, Chas Honton wrote: > Definitely create interfaces. > I agree 100% and will proceed. I thought about it overnight and it does not make sense to leave a mix of abstract classes and interfaces in StrSubstitutor. Gary > > Chas > > > On Feb 11, 2018, at 1:57 PM, Gary Gregory > wrote: > > > > On Sun, Feb 11, 2018 at 2:46 PM, Gary Gregory > > wrote: > > > >> > >> > >> On Sun, Feb 11, 2018 at 12:05 PM, Pascal Schumacher < > >> pascalschumac...@gmx.net> wrote: > >> > Am 11.02.2018 um 19:24 schrieb Gary Gregory: > > I'd like a code review and then a release of 1.3. Right now we only > depend > on java.base and Commons Lang, so let's keep it that way for 1.3 I > think. > > >>> My comments: > >>> > >> > >> Thank you for the code review! > >> > >> > >>> - Given "TEXT-80: StrLookup API confusing generic type parameter" I > think > >>> we should deprecate the old StrLookup class and mark it for removal in > >>> commons-text 2.0. > >>> > >> +1 and will do. > >> > >> > >>> - DateStringLookup: should we use FastDateFormat? > >>> > >> > >> I overlooked that one, I'll look into it. > >> > >> > >>> - AbstractStringLookup: empty class, I would therefore remove it. > >>> > >> > >> I like to have it around for now, it is package private anyway. We can > >> remove it before 1.3 if it stays empty. At one point I have an > >> isEmpty(String) method in there before I realized that Commons Text > depends > >> on Commons Lang which provides the same service in > >> StringUtils.isEmpty(String). > >> > >> > >>> - StringLookupFactory: should this be a static factory, to make it > easier > >>> to use? > >> > >> > >> I am leaving room for configuring these things later so I feel that > doing > >> .INSTANCE is a small price to pay but I hear you. > >> > > > > Oh, and consider this alternative: > > > > - Create StringLookup (already there) and StringSubstitutor > > - Deprecate StrLookup and StrSubstitutor and leave as is from 1.2 > > - ALSO deprecate StrMatcher which is a class and introduce a > StringMatcher > > _interface_. > > > > The idea here is to avoid having to do this a second time later. Right > now > > StrLookup and StrMatcher are classes, there are no interfaces. The > question > > is: Should we just redo the whole thing based on interfaces now. As of > now > > in master, we have a 50/50 situation with StrSubstituor supporting both > > StrLookup and StringLookup AND using StrMatcher (a class, not an > interface). > > > > Thoughts? > > > > Gary > > > > > >> Gary > >> > >> > >>> > >>> > >>> (I almost added Log4j's JNDI lookup but I know that will not work on > Android so I'd like to leave stuff like that for later, maybe in a > different module.) > > >>> +1 for leaving it out > >>> > >>> -Pascal > >>> > >>> > >>> - > >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>> For additional commands, e-mail: dev-h...@commons.apache.org > >>> > >>> > >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [text] Adapt the Log4j 2 Interpolator to [text]
Definitely create interfaces. Chas > On Feb 11, 2018, at 1:57 PM, Gary Gregory wrote: > > On Sun, Feb 11, 2018 at 2:46 PM, Gary Gregory > wrote: > >> >> >> On Sun, Feb 11, 2018 at 12:05 PM, Pascal Schumacher < >> pascalschumac...@gmx.net> wrote: >> Am 11.02.2018 um 19:24 schrieb Gary Gregory: I'd like a code review and then a release of 1.3. Right now we only depend on java.base and Commons Lang, so let's keep it that way for 1.3 I think. >>> My comments: >>> >> >> Thank you for the code review! >> >> >>> - Given "TEXT-80: StrLookup API confusing generic type parameter" I think >>> we should deprecate the old StrLookup class and mark it for removal in >>> commons-text 2.0. >>> >> +1 and will do. >> >> >>> - DateStringLookup: should we use FastDateFormat? >>> >> >> I overlooked that one, I'll look into it. >> >> >>> - AbstractStringLookup: empty class, I would therefore remove it. >>> >> >> I like to have it around for now, it is package private anyway. We can >> remove it before 1.3 if it stays empty. At one point I have an >> isEmpty(String) method in there before I realized that Commons Text depends >> on Commons Lang which provides the same service in >> StringUtils.isEmpty(String). >> >> >>> - StringLookupFactory: should this be a static factory, to make it easier >>> to use? >> >> >> I am leaving room for configuring these things later so I feel that doing >> .INSTANCE is a small price to pay but I hear you. >> > > Oh, and consider this alternative: > > - Create StringLookup (already there) and StringSubstitutor > - Deprecate StrLookup and StrSubstitutor and leave as is from 1.2 > - ALSO deprecate StrMatcher which is a class and introduce a StringMatcher > _interface_. > > The idea here is to avoid having to do this a second time later. Right now > StrLookup and StrMatcher are classes, there are no interfaces. The question > is: Should we just redo the whole thing based on interfaces now. As of now > in master, we have a 50/50 situation with StrSubstituor supporting both > StrLookup and StringLookup AND using StrMatcher (a class, not an interface). > > Thoughts? > > Gary > > >> Gary >> >> >>> >>> >>> (I almost added Log4j's JNDI lookup but I know that will not work on Android so I'd like to leave stuff like that for later, maybe in a different module.) >>> +1 for leaving it out >>> >>> -Pascal >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [text] Adapt the Log4j 2 Interpolator to [text]
On Sun, Feb 11, 2018 at 2:46 PM, Gary Gregory wrote: > > > On Sun, Feb 11, 2018 at 12:05 PM, Pascal Schumacher < > pascalschumac...@gmx.net> wrote: > >> Am 11.02.2018 um 19:24 schrieb Gary Gregory: >> >>> I'd like a code review and then a release of 1.3. Right now we only >>> depend >>> on java.base and Commons Lang, so let's keep it that way for 1.3 I think. >>> >> My comments: >> > > Thank you for the code review! > > >> - Given "TEXT-80: StrLookup API confusing generic type parameter" I think >> we should deprecate the old StrLookup class and mark it for removal in >> commons-text 2.0. >> > +1 and will do. > > >> - DateStringLookup: should we use FastDateFormat? >> > > I overlooked that one, I'll look into it. > > >> - AbstractStringLookup: empty class, I would therefore remove it. >> > > I like to have it around for now, it is package private anyway. We can > remove it before 1.3 if it stays empty. At one point I have an > isEmpty(String) method in there before I realized that Commons Text depends > on Commons Lang which provides the same service in > StringUtils.isEmpty(String). > > >> - StringLookupFactory: should this be a static factory, to make it easier >> to use? > > > I am leaving room for configuring these things later so I feel that doing > .INSTANCE is a small price to pay but I hear you. > Oh, and consider this alternative: - Create StringLookup (already there) and StringSubstitutor - Deprecate StrLookup and StrSubstitutor and leave as is from 1.2 - ALSO deprecate StrMatcher which is a class and introduce a StringMatcher _interface_. The idea here is to avoid having to do this a second time later. Right now StrLookup and StrMatcher are classes, there are no interfaces. The question is: Should we just redo the whole thing based on interfaces now. As of now in master, we have a 50/50 situation with StrSubstituor supporting both StrLookup and StringLookup AND using StrMatcher (a class, not an interface). Thoughts? Gary > Gary > > >> >> >> (I almost added Log4j's JNDI lookup but I know that will not work on >>> Android so I'd like to leave stuff like that for later, maybe in a >>> different module.) >>> >> +1 for leaving it out >> >> -Pascal >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> >
Re: [text] Adapt the Log4j 2 Interpolator to [text]
On Sun, Feb 11, 2018 at 12:05 PM, Pascal Schumacher < pascalschumac...@gmx.net> wrote: > Am 11.02.2018 um 19:24 schrieb Gary Gregory: > >> I'd like a code review and then a release of 1.3. Right now we only depend >> on java.base and Commons Lang, so let's keep it that way for 1.3 I think. >> > My comments: > Thank you for the code review! > - Given "TEXT-80: StrLookup API confusing generic type parameter" I think > we should deprecate the old StrLookup class and mark it for removal in > commons-text 2.0. > +1 and will do. > - DateStringLookup: should we use FastDateFormat? > I overlooked that one, I'll look into it. > - AbstractStringLookup: empty class, I would therefore remove it. > I like to have it around for now, it is package private anyway. We can remove it before 1.3 if it stays empty. At one point I have an isEmpty(String) method in there before I realized that Commons Text depends on Commons Lang which provides the same service in StringUtils.isEmpty(String). > - StringLookupFactory: should this be a static factory, to make it easier > to use? I am leaving room for configuring these things later so I feel that doing .INSTANCE is a small price to pay but I hear you. Gary > > > (I almost added Log4j's JNDI lookup but I know that will not work on >> Android so I'd like to leave stuff like that for later, maybe in a >> different module.) >> > +1 for leaving it out > > -Pascal > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [text] Adapt the Log4j 2 Interpolator to [text]
Am 11.02.2018 um 19:24 schrieb Gary Gregory: I'd like a code review and then a release of 1.3. Right now we only depend on java.base and Commons Lang, so let's keep it that way for 1.3 I think. My comments: - Given "TEXT-80: StrLookup API confusing generic type parameter" I think we should deprecate the old StrLookup class and mark it for removal in commons-text 2.0. - DateStringLookup: should we use FastDateFormat? - AbstractStringLookup: empty class, I would therefore remove it. - StringLookupFactory: should this be a static factory, to make it easier to use? (I almost added Log4j's JNDI lookup but I know that will not work on Android so I'd like to leave stuff like that for later, maybe in a different module.) +1 for leaving it out -Pascal - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [text] Adapt the Log4j 2 Interpolator to [text]
> On Feb 11, 2018, at 1:24 PM, Gary Gregory wrote:
>
> On Sun, Feb 11, 2018 at 11:10 AM, Gary Gregory
> wrote:
>
>> On Sun, Feb 11, 2018 at 4:40 AM, Pascal Schumacher <
>> pascalschumac...@gmx.net> wrote:
>>
>>> Hi Gary,
>>>
>>> thanks for adding this, looks useful. +1
>>>
>>> Please fix the checkstyle violations.
>>>
>>
>> Done but there is one checkstyle "Error" left for a TODO comment I left in
>> the code.
>>
>
> I'd like a code review and then a release of 1.3. Right now we only depend
> on java.base and Commons Lang, so let's keep it that way for 1.3 I think.
>
> (I almost added Log4j's JNDI lookup but I know that will not work on
> Android so I'd like to leave stuff like that for later, maybe in a
> different module.)
>
Curious if anyone has used the release plugin yet? I could try to pick this up
over the next week or so.
-Rob
> Gary
>
>
>>
>> Gary
>>
>>
>>> Thanks!
>>>
>>> - Pascal
>>>
>>>
>>>> Am 11.02.2018 um 01:32 schrieb Gary Gregory:
>>>>
>>>> On Sat, Feb 10, 2018 at 12:44 PM, Gary Gregory
>>>> wrote:
>>>>
>>>> I created the ticket "[TEXT-113] Add an interpolator string lookup." and
>>>>> committed a working version with unit tests.
>>>>>
>>>>> Please note:
>>>>> - The code is in a new package o.a.c.t.lookup and I left the current
>>>>> code as intact as possible.
>>>>> - The current StrLookup and StrMatcher are abstract classes and not
>>>>> interfaces. This is a problem IMO.
>>>>> - I introduced an interface called o.a.c.t.lookup.StringLookup.
>>>>> - I did nothing to deal with StrMatcher as I have no need for a clean
>>>>> extension mechanism there.
>>>>> - We could add searching for lookups with a serice loader. I do not need
>>>>> this for now, so I did not bother.
>>>>> - The private lookup classes in StrLookup will likely be replaced by
>>>>> o.a.c.t.lookup
>>>>> classes. I did not do this yet to minimize the changes for this round.
>>>>>
>>>>> Please review. I can use this now in a couple of projects more cleanly
>>>>> instead of reusing the guts of Log4j which includes similar code.
>>>>>
>>>>> I committed some small improvements to the Javadoc. The next element to
>>>> consider is whether to deprecate the StrSubstitutor ctors that take
>>>> StrLookup (the class) in favor of ctors that take StringLookup (the
>>>> interface).
>>>>
>>>> The wrinkle there is what to do with StrSubstitutor.getVariableReso
>>>> lver().
>>>> First, I would add a new getter StrSubstitutor.getStringLookup() and
>>>> change
>>>> this ivar from StrLookup to StringLookup. Second, would be for
>>>> StrSubstitutor.getVariableResolver()
>>>> to cast it return value to StringLookup and let that throw a
>>>> ClassCastException if the StringLookup ivar does not hold an impl of
>>>> StringLookup.
>>>>
>>>> Thoughts?
>>>>
>>>> Gary
>>>>
>>>>
>>>> Thank you,
>>>>> Gary
>>>>>
>>>>> On Thu, Dec 14, 2017 at 2:40 PM, Rob Tompkins
>>>>> wrote:
>>>>>
>>>>>
>>>>>> On Dec 14, 2017, at 4:11 PM, Gary Gregory
>>>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>> I think I'll pick Commons Config as the starting point, unless someone
>>>>>>>
>>>>>> else
>>>>>>
>>>>>>> has a stronger POV.
>>>>>>>
>>>>>> +1
>>>>>>
>>>>>> Gary
>>>>>>>
>>>>>>> On Thu, Dec 14, 2017 at 12:59 PM, Jan Matèrne (jhm) <
>>>>>>> apa...@materne.de>
>>>>>>> wrote:
>>>>>>>
>>>>>>> If I see a syntax like ${prefix:key} I could think of having a map of
>>>>>>>>
>>>>>>> "map
>>>>>>
>>>>>>> providers".
>>>>>>>> The source of such a map could be a file, system properties,
>>>>>>
Re: [text] Adapt the Log4j 2 Interpolator to [text]
Am 11.02.2018 um 19:10 schrieb Gary Gregory: Done but there is one checkstyle "Error" left for a TODO comment I left in the code. Thanks! - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [text] Adapt the Log4j 2 Interpolator to [text]
On Sun, Feb 11, 2018 at 11:10 AM, Gary Gregory
wrote:
> On Sun, Feb 11, 2018 at 4:40 AM, Pascal Schumacher <
> pascalschumac...@gmx.net> wrote:
>
>> Hi Gary,
>>
>> thanks for adding this, looks useful. +1
>>
>> Please fix the checkstyle violations.
>>
>
> Done but there is one checkstyle "Error" left for a TODO comment I left in
> the code.
>
I'd like a code review and then a release of 1.3. Right now we only depend
on java.base and Commons Lang, so let's keep it that way for 1.3 I think.
(I almost added Log4j's JNDI lookup but I know that will not work on
Android so I'd like to leave stuff like that for later, maybe in a
different module.)
Gary
>
> Gary
>
>
>> Thanks!
>>
>> - Pascal
>>
>>
>> Am 11.02.2018 um 01:32 schrieb Gary Gregory:
>>
>>> On Sat, Feb 10, 2018 at 12:44 PM, Gary Gregory
>>> wrote:
>>>
>>> I created the ticket "[TEXT-113] Add an interpolator string lookup." and
>>>> committed a working version with unit tests.
>>>>
>>>> Please note:
>>>> - The code is in a new package o.a.c.t.lookup and I left the current
>>>> code as intact as possible.
>>>> - The current StrLookup and StrMatcher are abstract classes and not
>>>> interfaces. This is a problem IMO.
>>>> - I introduced an interface called o.a.c.t.lookup.StringLookup.
>>>> - I did nothing to deal with StrMatcher as I have no need for a clean
>>>> extension mechanism there.
>>>> - We could add searching for lookups with a serice loader. I do not need
>>>> this for now, so I did not bother.
>>>> - The private lookup classes in StrLookup will likely be replaced by
>>>> o.a.c.t.lookup
>>>> classes. I did not do this yet to minimize the changes for this round.
>>>>
>>>> Please review. I can use this now in a couple of projects more cleanly
>>>> instead of reusing the guts of Log4j which includes similar code.
>>>>
>>>> I committed some small improvements to the Javadoc. The next element to
>>> consider is whether to deprecate the StrSubstitutor ctors that take
>>> StrLookup (the class) in favor of ctors that take StringLookup (the
>>> interface).
>>>
>>> The wrinkle there is what to do with StrSubstitutor.getVariableReso
>>> lver().
>>> First, I would add a new getter StrSubstitutor.getStringLookup() and
>>> change
>>> this ivar from StrLookup to StringLookup. Second, would be for
>>> StrSubstitutor.getVariableResolver()
>>> to cast it return value to StringLookup and let that throw a
>>> ClassCastException if the StringLookup ivar does not hold an impl of
>>> StringLookup.
>>>
>>> Thoughts?
>>>
>>> Gary
>>>
>>>
>>> Thank you,
>>>> Gary
>>>>
>>>> On Thu, Dec 14, 2017 at 2:40 PM, Rob Tompkins
>>>> wrote:
>>>>
>>>>
>>>>> On Dec 14, 2017, at 4:11 PM, Gary Gregory
>>>>>>
>>>>> wrote:
>>>>>
>>>>>> I think I'll pick Commons Config as the starting point, unless someone
>>>>>>
>>>>> else
>>>>>
>>>>>> has a stronger POV.
>>>>>>
>>>>> +1
>>>>>
>>>>> Gary
>>>>>>
>>>>>> On Thu, Dec 14, 2017 at 12:59 PM, Jan Matèrne (jhm) <
>>>>>> apa...@materne.de>
>>>>>> wrote:
>>>>>>
>>>>>> If I see a syntax like ${prefix:key} I could think of having a map of
>>>>>>>
>>>>>> "map
>>>>>
>>>>>> providers".
>>>>>>> The source of such a map could be a file, system properties,
>>>>>>>
>>>>>> environment
>>>>>
>>>>>> variables, database, ldap, ...
>>>>>>>
>>>>>>> Haven't looked at commons-configuration.
>>>>>>> But maybe also have a look at Apache Deltaspike which supports
>>>>>>> configurtion values via a "Datasource".
>>>>>>>
>>>>>>> And Tamaya will also have one, I think ...
>>>>>>>
>>>>>>>
>>>>>>> Jan
>>>>>>>
>>>>>>>
>>>>>>>
>>&
Re: [text] Adapt the Log4j 2 Interpolator to [text]
On Sun, Feb 11, 2018 at 4:40 AM, Pascal Schumacher wrote:
> Hi Gary,
>
> thanks for adding this, looks useful. +1
>
> Please fix the checkstyle violations.
>
Done but there is one checkstyle "Error" left for a TODO comment I left in
the code.
Gary
> Thanks!
>
> - Pascal
>
>
> Am 11.02.2018 um 01:32 schrieb Gary Gregory:
>
>> On Sat, Feb 10, 2018 at 12:44 PM, Gary Gregory
>> wrote:
>>
>> I created the ticket "[TEXT-113] Add an interpolator string lookup." and
>>> committed a working version with unit tests.
>>>
>>> Please note:
>>> - The code is in a new package o.a.c.t.lookup and I left the current
>>> code as intact as possible.
>>> - The current StrLookup and StrMatcher are abstract classes and not
>>> interfaces. This is a problem IMO.
>>> - I introduced an interface called o.a.c.t.lookup.StringLookup.
>>> - I did nothing to deal with StrMatcher as I have no need for a clean
>>> extension mechanism there.
>>> - We could add searching for lookups with a serice loader. I do not need
>>> this for now, so I did not bother.
>>> - The private lookup classes in StrLookup will likely be replaced by
>>> o.a.c.t.lookup
>>> classes. I did not do this yet to minimize the changes for this round.
>>>
>>> Please review. I can use this now in a couple of projects more cleanly
>>> instead of reusing the guts of Log4j which includes similar code.
>>>
>>> I committed some small improvements to the Javadoc. The next element to
>> consider is whether to deprecate the StrSubstitutor ctors that take
>> StrLookup (the class) in favor of ctors that take StringLookup (the
>> interface).
>>
>> The wrinkle there is what to do with StrSubstitutor.getVariableReso
>> lver().
>> First, I would add a new getter StrSubstitutor.getStringLookup() and
>> change
>> this ivar from StrLookup to StringLookup. Second, would be for
>> StrSubstitutor.getVariableResolver()
>> to cast it return value to StringLookup and let that throw a
>> ClassCastException if the StringLookup ivar does not hold an impl of
>> StringLookup.
>>
>> Thoughts?
>>
>> Gary
>>
>>
>> Thank you,
>>> Gary
>>>
>>> On Thu, Dec 14, 2017 at 2:40 PM, Rob Tompkins
>>> wrote:
>>>
>>>
>>>> On Dec 14, 2017, at 4:11 PM, Gary Gregory
>>>>>
>>>> wrote:
>>>>
>>>>> I think I'll pick Commons Config as the starting point, unless someone
>>>>>
>>>> else
>>>>
>>>>> has a stronger POV.
>>>>>
>>>> +1
>>>>
>>>> Gary
>>>>>
>>>>> On Thu, Dec 14, 2017 at 12:59 PM, Jan Matèrne (jhm) >>>> >
>>>>> wrote:
>>>>>
>>>>> If I see a syntax like ${prefix:key} I could think of having a map of
>>>>>>
>>>>> "map
>>>>
>>>>> providers".
>>>>>> The source of such a map could be a file, system properties,
>>>>>>
>>>>> environment
>>>>
>>>>> variables, database, ldap, ...
>>>>>>
>>>>>> Haven't looked at commons-configuration.
>>>>>> But maybe also have a look at Apache Deltaspike which supports
>>>>>> configurtion values via a "Datasource".
>>>>>>
>>>>>> And Tamaya will also have one, I think ...
>>>>>>
>>>>>>
>>>>>> Jan
>>>>>>
>>>>>>
>>>>>>
>>>>>> -Ursprüngliche Nachricht-
>>>>>>> Von: Ralph Goers [mailto:ralph.go...@dslextreme.com]
>>>>>>> Gesendet: Donnerstag, 14. Dezember 2017 16:41
>>>>>>> An: Commons Developers List
>>>>>>> Betreff: Re: [text] Adapt the Log4j 2 Interpolator to [text]
>>>>>>>
>>>>>>> Yes, the Interpolator was borrowed from Commons Configuration.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Dec 14, 2017, at 5:20 AM, Jörg Schaible >>>>>>>
>>>>>>> inspire.com> wrote:
>>>>>>>
>>>>>>>> Hi Gary,
>>>>>>>>
>>>>>>>> Am Wed, 13 Dec 2017 15:17:56 -0700 schrieb Gary G
Re: [text] Adapt the Log4j 2 Interpolator to [text]
Hi Gary,
thanks for adding this, looks useful. +1
Please fix the checkstyle violations.
Thanks!
- Pascal
Am 11.02.2018 um 01:32 schrieb Gary Gregory:
On Sat, Feb 10, 2018 at 12:44 PM, Gary Gregory
wrote:
I created the ticket "[TEXT-113] Add an interpolator string lookup." and
committed a working version with unit tests.
Please note:
- The code is in a new package o.a.c.t.lookup and I left the current
code as intact as possible.
- The current StrLookup and StrMatcher are abstract classes and not
interfaces. This is a problem IMO.
- I introduced an interface called o.a.c.t.lookup.StringLookup.
- I did nothing to deal with StrMatcher as I have no need for a clean
extension mechanism there.
- We could add searching for lookups with a serice loader. I do not need
this for now, so I did not bother.
- The private lookup classes in StrLookup will likely be replaced by
o.a.c.t.lookup
classes. I did not do this yet to minimize the changes for this round.
Please review. I can use this now in a couple of projects more cleanly
instead of reusing the guts of Log4j which includes similar code.
I committed some small improvements to the Javadoc. The next element to
consider is whether to deprecate the StrSubstitutor ctors that take
StrLookup (the class) in favor of ctors that take StringLookup (the
interface).
The wrinkle there is what to do with StrSubstitutor.getVariableResolver().
First, I would add a new getter StrSubstitutor.getStringLookup() and change
this ivar from StrLookup to StringLookup. Second, would be for
StrSubstitutor.getVariableResolver()
to cast it return value to StringLookup and let that throw a
ClassCastException if the StringLookup ivar does not hold an impl of
StringLookup.
Thoughts?
Gary
Thank you,
Gary
On Thu, Dec 14, 2017 at 2:40 PM, Rob Tompkins wrote:
On Dec 14, 2017, at 4:11 PM, Gary Gregory
wrote:
I think I'll pick Commons Config as the starting point, unless someone
else
has a stronger POV.
+1
Gary
On Thu, Dec 14, 2017 at 12:59 PM, Jan Matèrne (jhm)
wrote:
If I see a syntax like ${prefix:key} I could think of having a map of
"map
providers".
The source of such a map could be a file, system properties,
environment
variables, database, ldap, ...
Haven't looked at commons-configuration.
But maybe also have a look at Apache Deltaspike which supports
configurtion values via a "Datasource".
And Tamaya will also have one, I think ...
Jan
-Ursprüngliche Nachricht-
Von: Ralph Goers [mailto:ralph.go...@dslextreme.com]
Gesendet: Donnerstag, 14. Dezember 2017 16:41
An: Commons Developers List
Betreff: Re: [text] Adapt the Log4j 2 Interpolator to [text]
Yes, the Interpolator was borrowed from Commons Configuration.
Ralph
On Dec 14, 2017, at 5:20 AM, Jörg Schaible
inspire.com> wrote:
Hi Gary,
Am Wed, 13 Dec 2017 15:17:56 -0700 schrieb Gary Gregory:
Hi All,
Log4j 2 provides it's own copy of our StrSubstitutor/StrLookup
framework enhanced for Log4j's needs. In addition it provides a
custom StrLookup called Interpolator which allows for lookups like:
${sys:java.version} and ${env:MY_VAR} to look up system properties
and environment variables respectively as well as other sub maps.
You will find this also in commons-configurations.
I would like to borrow this concept of a composite and keyed
StrLookup and make it a first class citizen in [text].
This would look like this:
Interpolator interpolator = new o.a.c.t.Interpolator();
interpolator.put("gary", StrLookup.mapLookup(new HashMap()));
interpolator.put("alice", StrLookup.mapLookup(new HashMap()));
StrSubstitutor strSubstitutor = new StrSubstitutor(interpolator);
Thoughts?
Cheers,
Jörg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [text] Adapt the Log4j 2 Interpolator to [text]
On Sat, Feb 10, 2018 at 12:44 PM, Gary Gregory
wrote:
> I created the ticket "[TEXT-113] Add an interpolator string lookup." and
> committed a working version with unit tests.
>
> Please note:
> - The code is in a new package o.a.c.t.lookup and I left the current
> code as intact as possible.
> - The current StrLookup and StrMatcher are abstract classes and not
> interfaces. This is a problem IMO.
> - I introduced an interface called o.a.c.t.lookup.StringLookup.
> - I did nothing to deal with StrMatcher as I have no need for a clean
> extension mechanism there.
> - We could add searching for lookups with a serice loader. I do not need
> this for now, so I did not bother.
> - The private lookup classes in StrLookup will likely be replaced by
> o.a.c.t.lookup
> classes. I did not do this yet to minimize the changes for this round.
>
> Please review. I can use this now in a couple of projects more cleanly
> instead of reusing the guts of Log4j which includes similar code.
>
I committed some small improvements to the Javadoc. The next element to
consider is whether to deprecate the StrSubstitutor ctors that take
StrLookup (the class) in favor of ctors that take StringLookup (the
interface).
The wrinkle there is what to do with StrSubstitutor.getVariableResolver().
First, I would add a new getter StrSubstitutor.getStringLookup() and change
this ivar from StrLookup to StringLookup. Second, would be for
StrSubstitutor.getVariableResolver()
to cast it return value to StringLookup and let that throw a
ClassCastException if the StringLookup ivar does not hold an impl of
StringLookup.
Thoughts?
Gary
> Thank you,
> Gary
>
> On Thu, Dec 14, 2017 at 2:40 PM, Rob Tompkins wrote:
>
>>
>>
>> > On Dec 14, 2017, at 4:11 PM, Gary Gregory
>> wrote:
>> >
>> > I think I'll pick Commons Config as the starting point, unless someone
>> else
>> > has a stronger POV.
>>
>> +1
>>
>> >
>> > Gary
>> >
>> > On Thu, Dec 14, 2017 at 12:59 PM, Jan Matèrne (jhm)
>> > wrote:
>> >
>> >> If I see a syntax like ${prefix:key} I could think of having a map of
>> "map
>> >> providers".
>> >> The source of such a map could be a file, system properties,
>> environment
>> >> variables, database, ldap, ...
>> >>
>> >> Haven't looked at commons-configuration.
>> >> But maybe also have a look at Apache Deltaspike which supports
>> >> configurtion values via a "Datasource".
>> >>
>> >> And Tamaya will also have one, I think ...
>> >>
>> >>
>> >> Jan
>> >>
>> >>
>> >>
>> >>> -Ursprüngliche Nachricht-
>> >>> Von: Ralph Goers [mailto:ralph.go...@dslextreme.com]
>> >>> Gesendet: Donnerstag, 14. Dezember 2017 16:41
>> >>> An: Commons Developers List
>> >>> Betreff: Re: [text] Adapt the Log4j 2 Interpolator to [text]
>> >>>
>> >>> Yes, the Interpolator was borrowed from Commons Configuration.
>> >>>
>> >>> Ralph
>> >>>
>> >>>> On Dec 14, 2017, at 5:20 AM, Jörg Schaible > >>> inspire.com> wrote:
>> >>>>
>> >>>> Hi Gary,
>> >>>>
>> >>>> Am Wed, 13 Dec 2017 15:17:56 -0700 schrieb Gary Gregory:
>> >>>>
>> >>>>> Hi All,
>> >>>>>
>> >>>>> Log4j 2 provides it's own copy of our StrSubstitutor/StrLookup
>> >>>>> framework enhanced for Log4j's needs. In addition it provides a
>> >>>>> custom StrLookup called Interpolator which allows for lookups like:
>> >>>>>
>> >>>>> ${sys:java.version} and ${env:MY_VAR} to look up system properties
>> >>>>> and environment variables respectively as well as other sub maps.
>> >>>>
>> >>>> You will find this also in commons-configurations.
>> >>>>
>> >>>>> I would like to borrow this concept of a composite and keyed
>> >>>>> StrLookup and make it a first class citizen in [text].
>> >>>>>
>> >>>>> This would look like this:
>> >>>>>
>> >>>>> Interpolator interpolator = new o.a.c.t.Interpolator();
>> >>>>> interpolator.put("gary", StrLookup.mapLookup(new HashMap()));
>> >>>>> interpolator.put("alice", StrLookup.mapLookup(new HashMap()));
>> >>>>> StrSubstitutor strSubstitutor = new StrSubstitutor(interpolator);
>> >>>>>
>> >>>>> Thoughts?
>> >>>>
>> >>>> Cheers,
>> >>>> Jörg
>> >>>>
>> >>>>
>> >>>>
>> -
>> >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >>>> For additional commands, e-mail: dev-h...@commons.apache.org
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> -
>> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >>> For additional commands, e-mail: dev-h...@commons.apache.org
>> >>
>> >>
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >> For additional commands, e-mail: dev-h...@commons.apache.org
>> >>
>> >>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
Re: [text] Adapt the Log4j 2 Interpolator to [text]
I created the ticket "[TEXT-113] Add an interpolator string lookup." and
committed a working version with unit tests.
Please note:
- The code is in a new package o.a.c.t.lookup and I left the current code
as intact as possible.
- The current StrLookup and StrMatcher are abstract classes and not
interfaces. This is a problem IMO.
- I introduced an interface called o.a.c.t.lookup.StringLookup.
- I did nothing to deal with StrMatcher as I have no need for a clean
extension mechanism there.
- We could add searching for lookups with a serice loader. I do not need
this for now, so I did not bother.
- The private lookup classes in StrLookup will likely be replaced by
o.a.c.t.lookup
classes. I did not do this yet to minimize the changes for this round.
Please review. I can use this now in a couple of projects more cleanly
instead of reusing the guts of Log4j which includes similar code.
Thank you,
Gary
On Thu, Dec 14, 2017 at 2:40 PM, Rob Tompkins wrote:
>
>
> > On Dec 14, 2017, at 4:11 PM, Gary Gregory
> wrote:
> >
> > I think I'll pick Commons Config as the starting point, unless someone
> else
> > has a stronger POV.
>
> +1
>
> >
> > Gary
> >
> > On Thu, Dec 14, 2017 at 12:59 PM, Jan Matèrne (jhm)
> > wrote:
> >
> >> If I see a syntax like ${prefix:key} I could think of having a map of
> "map
> >> providers".
> >> The source of such a map could be a file, system properties, environment
> >> variables, database, ldap, ...
> >>
> >> Haven't looked at commons-configuration.
> >> But maybe also have a look at Apache Deltaspike which supports
> >> configurtion values via a "Datasource".
> >>
> >> And Tamaya will also have one, I think ...
> >>
> >>
> >> Jan
> >>
> >>
> >>
> >>> -Ursprüngliche Nachricht-
> >>> Von: Ralph Goers [mailto:ralph.go...@dslextreme.com]
> >>> Gesendet: Donnerstag, 14. Dezember 2017 16:41
> >>> An: Commons Developers List
> >>> Betreff: Re: [text] Adapt the Log4j 2 Interpolator to [text]
> >>>
> >>> Yes, the Interpolator was borrowed from Commons Configuration.
> >>>
> >>> Ralph
> >>>
> >>>> On Dec 14, 2017, at 5:20 AM, Jörg Schaible >>> inspire.com> wrote:
> >>>>
> >>>> Hi Gary,
> >>>>
> >>>> Am Wed, 13 Dec 2017 15:17:56 -0700 schrieb Gary Gregory:
> >>>>
> >>>>> Hi All,
> >>>>>
> >>>>> Log4j 2 provides it's own copy of our StrSubstitutor/StrLookup
> >>>>> framework enhanced for Log4j's needs. In addition it provides a
> >>>>> custom StrLookup called Interpolator which allows for lookups like:
> >>>>>
> >>>>> ${sys:java.version} and ${env:MY_VAR} to look up system properties
> >>>>> and environment variables respectively as well as other sub maps.
> >>>>
> >>>> You will find this also in commons-configurations.
> >>>>
> >>>>> I would like to borrow this concept of a composite and keyed
> >>>>> StrLookup and make it a first class citizen in [text].
> >>>>>
> >>>>> This would look like this:
> >>>>>
> >>>>> Interpolator interpolator = new o.a.c.t.Interpolator();
> >>>>> interpolator.put("gary", StrLookup.mapLookup(new HashMap()));
> >>>>> interpolator.put("alice", StrLookup.mapLookup(new HashMap()));
> >>>>> StrSubstitutor strSubstitutor = new StrSubstitutor(interpolator);
> >>>>>
> >>>>> Thoughts?
> >>>>
> >>>> Cheers,
> >>>> Jörg
> >>>>
> >>>>
> >>>> -
> >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
Re: [text] Adapt the Log4j 2 Interpolator to [text]
> On Dec 14, 2017, at 4:11 PM, Gary Gregory wrote:
>
> I think I'll pick Commons Config as the starting point, unless someone else
> has a stronger POV.
+1
>
> Gary
>
> On Thu, Dec 14, 2017 at 12:59 PM, Jan Matèrne (jhm)
> wrote:
>
>> If I see a syntax like ${prefix:key} I could think of having a map of "map
>> providers".
>> The source of such a map could be a file, system properties, environment
>> variables, database, ldap, ...
>>
>> Haven't looked at commons-configuration.
>> But maybe also have a look at Apache Deltaspike which supports
>> configurtion values via a "Datasource".
>>
>> And Tamaya will also have one, I think ...
>>
>>
>> Jan
>>
>>
>>
>>> -Ursprüngliche Nachricht-----
>>> Von: Ralph Goers [mailto:ralph.go...@dslextreme.com]
>>> Gesendet: Donnerstag, 14. Dezember 2017 16:41
>>> An: Commons Developers List
>>> Betreff: Re: [text] Adapt the Log4j 2 Interpolator to [text]
>>>
>>> Yes, the Interpolator was borrowed from Commons Configuration.
>>>
>>> Ralph
>>>
>>>> On Dec 14, 2017, at 5:20 AM, Jörg Schaible >> inspire.com> wrote:
>>>>
>>>> Hi Gary,
>>>>
>>>> Am Wed, 13 Dec 2017 15:17:56 -0700 schrieb Gary Gregory:
>>>>
>>>>> Hi All,
>>>>>
>>>>> Log4j 2 provides it's own copy of our StrSubstitutor/StrLookup
>>>>> framework enhanced for Log4j's needs. In addition it provides a
>>>>> custom StrLookup called Interpolator which allows for lookups like:
>>>>>
>>>>> ${sys:java.version} and ${env:MY_VAR} to look up system properties
>>>>> and environment variables respectively as well as other sub maps.
>>>>
>>>> You will find this also in commons-configurations.
>>>>
>>>>> I would like to borrow this concept of a composite and keyed
>>>>> StrLookup and make it a first class citizen in [text].
>>>>>
>>>>> This would look like this:
>>>>>
>>>>> Interpolator interpolator = new o.a.c.t.Interpolator();
>>>>> interpolator.put("gary", StrLookup.mapLookup(new HashMap()));
>>>>> interpolator.put("alice", StrLookup.mapLookup(new HashMap()));
>>>>> StrSubstitutor strSubstitutor = new StrSubstitutor(interpolator);
>>>>>
>>>>> Thoughts?
>>>>
>>>> Cheers,
>>>> Jörg
>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [text] Adapt the Log4j 2 Interpolator to [text]
I think I'll pick Commons Config as the starting point, unless someone else
has a stronger POV.
Gary
On Thu, Dec 14, 2017 at 12:59 PM, Jan Matèrne (jhm)
wrote:
> If I see a syntax like ${prefix:key} I could think of having a map of "map
> providers".
> The source of such a map could be a file, system properties, environment
> variables, database, ldap, ...
>
> Haven't looked at commons-configuration.
> But maybe also have a look at Apache Deltaspike which supports
> configurtion values via a "Datasource".
>
> And Tamaya will also have one, I think ...
>
>
> Jan
>
>
>
> > -Ursprüngliche Nachricht-
> > Von: Ralph Goers [mailto:ralph.go...@dslextreme.com]
> > Gesendet: Donnerstag, 14. Dezember 2017 16:41
> > An: Commons Developers List
> > Betreff: Re: [text] Adapt the Log4j 2 Interpolator to [text]
> >
> > Yes, the Interpolator was borrowed from Commons Configuration.
> >
> > Ralph
> >
> > > On Dec 14, 2017, at 5:20 AM, Jörg Schaible > inspire.com> wrote:
> > >
> > > Hi Gary,
> > >
> > > Am Wed, 13 Dec 2017 15:17:56 -0700 schrieb Gary Gregory:
> > >
> > >> Hi All,
> > >>
> > >> Log4j 2 provides it's own copy of our StrSubstitutor/StrLookup
> > >> framework enhanced for Log4j's needs. In addition it provides a
> > >> custom StrLookup called Interpolator which allows for lookups like:
> > >>
> > >> ${sys:java.version} and ${env:MY_VAR} to look up system properties
> > >> and environment variables respectively as well as other sub maps.
> > >
> > > You will find this also in commons-configurations.
> > >
> > >> I would like to borrow this concept of a composite and keyed
> > >> StrLookup and make it a first class citizen in [text].
> > >>
> > >> This would look like this:
> > >>
> > >> Interpolator interpolator = new o.a.c.t.Interpolator();
> > >> interpolator.put("gary", StrLookup.mapLookup(new HashMap()));
> > >> interpolator.put("alice", StrLookup.mapLookup(new HashMap()));
> > >> StrSubstitutor strSubstitutor = new StrSubstitutor(interpolator);
> > >>
> > >> Thoughts?
> > >
> > > Cheers,
> > > Jörg
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
AW: [text] Adapt the Log4j 2 Interpolator to [text]
If I see a syntax like ${prefix:key} I could think of having a map of "map
providers".
The source of such a map could be a file, system properties, environment
variables, database, ldap, ...
Haven't looked at commons-configuration.
But maybe also have a look at Apache Deltaspike which supports configurtion
values via a "Datasource".
And Tamaya will also have one, I think ...
Jan
> -Ursprüngliche Nachricht-
> Von: Ralph Goers [mailto:ralph.go...@dslextreme.com]
> Gesendet: Donnerstag, 14. Dezember 2017 16:41
> An: Commons Developers List
> Betreff: Re: [text] Adapt the Log4j 2 Interpolator to [text]
>
> Yes, the Interpolator was borrowed from Commons Configuration.
>
> Ralph
>
> > On Dec 14, 2017, at 5:20 AM, Jörg Schaible inspire.com> wrote:
> >
> > Hi Gary,
> >
> > Am Wed, 13 Dec 2017 15:17:56 -0700 schrieb Gary Gregory:
> >
> >> Hi All,
> >>
> >> Log4j 2 provides it's own copy of our StrSubstitutor/StrLookup
> >> framework enhanced for Log4j's needs. In addition it provides a
> >> custom StrLookup called Interpolator which allows for lookups like:
> >>
> >> ${sys:java.version} and ${env:MY_VAR} to look up system properties
> >> and environment variables respectively as well as other sub maps.
> >
> > You will find this also in commons-configurations.
> >
> >> I would like to borrow this concept of a composite and keyed
> >> StrLookup and make it a first class citizen in [text].
> >>
> >> This would look like this:
> >>
> >> Interpolator interpolator = new o.a.c.t.Interpolator();
> >> interpolator.put("gary", StrLookup.mapLookup(new HashMap()));
> >> interpolator.put("alice", StrLookup.mapLookup(new HashMap()));
> >> StrSubstitutor strSubstitutor = new StrSubstitutor(interpolator);
> >>
> >> Thoughts?
> >
> > Cheers,
> > Jörg
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [text] Adapt the Log4j 2 Interpolator to [text]
Yes, the Interpolator was borrowed from Commons Configuration.
Ralph
> On Dec 14, 2017, at 5:20 AM, Jörg Schaible
> wrote:
>
> Hi Gary,
>
> Am Wed, 13 Dec 2017 15:17:56 -0700 schrieb Gary Gregory:
>
>> Hi All,
>>
>> Log4j 2 provides it's own copy of our StrSubstitutor/StrLookup framework
>> enhanced for Log4j's needs. In addition it provides a custom StrLookup
>> called Interpolator which allows for lookups like:
>>
>> ${sys:java.version} and ${env:MY_VAR} to look up system properties and
>> environment variables respectively as well as other sub maps.
>
> You will find this also in commons-configurations.
>
>> I would like to borrow this concept of a composite and keyed StrLookup
>> and make it a first class citizen in [text].
>>
>> This would look like this:
>>
>> Interpolator interpolator = new o.a.c.t.Interpolator();
>> interpolator.put("gary", StrLookup.mapLookup(new HashMap()));
>> interpolator.put("alice", StrLookup.mapLookup(new HashMap()));
>> StrSubstitutor strSubstitutor = new StrSubstitutor(interpolator);
>>
>> Thoughts?
>
> Cheers,
> Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [text] Adapt the Log4j 2 Interpolator to [text]
Hi Gary,
Am Wed, 13 Dec 2017 15:17:56 -0700 schrieb Gary Gregory:
> Hi All,
>
> Log4j 2 provides it's own copy of our StrSubstitutor/StrLookup framework
> enhanced for Log4j's needs. In addition it provides a custom StrLookup
> called Interpolator which allows for lookups like:
>
> ${sys:java.version} and ${env:MY_VAR} to look up system properties and
> environment variables respectively as well as other sub maps.
You will find this also in commons-configurations.
> I would like to borrow this concept of a composite and keyed StrLookup
> and make it a first class citizen in [text].
>
> This would look like this:
>
> Interpolator interpolator = new o.a.c.t.Interpolator();
> interpolator.put("gary", StrLookup.mapLookup(new HashMap()));
> interpolator.put("alice", StrLookup.mapLookup(new HashMap()));
> StrSubstitutor strSubstitutor = new StrSubstitutor(interpolator);
>
> Thoughts?
Cheers,
Jörg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[text] Adapt the Log4j 2 Interpolator to [text]
Hi All,
Log4j 2 provides it's own copy of our StrSubstitutor/StrLookup framework
enhanced for Log4j's needs. In addition it provides a custom StrLookup
called Interpolator which allows for lookups like:
${sys:java.version} and ${env:MY_VAR} to look up system properties and
environment variables respectively as well as other sub maps.
I would like to borrow this concept of a composite and keyed StrLookup and
make it a first class citizen in [text].
This would look like this:
Interpolator interpolator = new o.a.c.t.Interpolator();
interpolator.put("gary", StrLookup.mapLookup(new HashMap()));
interpolator.put("alice", StrLookup.mapLookup(new HashMap()));
StrSubstitutor strSubstitutor = new StrSubstitutor(interpolator);
Thoughts?
Gary
