Re: [text] Adapt the Log4j 2 Interpolator to [text]

[Gary Gregory]

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]

[Pascal Schumacher]

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]

[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:
>
>> 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]

[Gary Gregory]

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]

[Pascal Schumacher]

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]

[Gary Gregory]

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]

[Chas Honton]

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]

[Gary Gregory]

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]

[Gary Gregory]

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]

[Pascal Schumacher]

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]

[Rob Tompkins]

> On Feb 11, 2018, at 1:24 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
> 
> On Sun, Feb 11, 2018 at 11:10 AM, Gary Gregory <garydgreg...@gmail.com>
> 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 <garydgreg...@gmail.com>
>>>> 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 <chtom...@gmail.com>
>>>>> wrote:
>>>>> 
>>>>> 
>>>>>> On Dec 14, 2017, at 4:11 PM, Gary Gregory <garydgreg...@gmail.com>
>>>>>>> 
>>>>>> 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&q

Re: [text] Adapt the Log4j 2 Interpolator to [text]

[Pascal Schumacher]

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]

[Gary Gregory]

On Sun, Feb 11, 2018 at 11:10 AM, Gary Gregory <garydgreg...@gmail.com>
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 <garydgreg...@gmail.com>
>>> 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 <chtom...@gmail.com>
>>>> wrote:
>>>>
>>>>
>>>>> On Dec 14, 2017, at 4:11 PM, Gary Gregory <garydgreg...@gmail.com>
>>>>>>
>>>>> 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]

[Gary Gregory]

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.

Gary


> Thanks!
>
> - Pascal
>
>
> Am 11.02.2018 um 01:32 schrieb Gary Gregory:
>
>> On Sat, Feb 10, 2018 at 12:44 PM, Gary Gregory <garydgreg...@gmail.com>
>> 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 <chtom...@gmail.com>
>>> wrote:
>>>
>>>
>>>> On Dec 14, 2017, at 4:11 PM, Gary Gregory <garydgreg...@gmail.com>
>>>>>
>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>> -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 <joerg.schaible@bpm-
>>>>>>>>
>>>>>>> inspire.com> wrote:
>>>>>>>

Re: [text] Adapt the Log4j 2 Interpolator to [text]

[Pascal Schumacher]

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 <garydgreg...@gmail.com>
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 <chtom...@gmail.com> wrote:




On Dec 14, 2017, at 4:11 PM, Gary Gregory <garydgreg...@gmail.com>

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




-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 <joerg.schaible@bpm-

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]

[Gary Gregory]

On Sat, Feb 10, 2018 at 12:44 PM, Gary Gregory <garydgreg...@gmail.com>
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 <chtom...@gmail.com> wrote:
>
>>
>>
>> > On Dec 14, 2017, at 4:11 PM, Gary Gregory <garydgreg...@gmail.com>
>> 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
>> >>
>> >>
>> >>
>> >>> -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 <joerg.schaible@bpm-
>> >>> 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();
>> >>>>&

Re: [text] Adapt the Log4j 2 Interpolator to [text]

[Gary Gregory]

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 <chtom...@gmail.com> wrote:

>
>
> > On Dec 14, 2017, at 4:11 PM, Gary Gregory <garydgreg...@gmail.com>
> 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
> >>
> >>
> >>
> >>> -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 <joerg.schaible@bpm-
> >>> 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]

[Rob Tompkins]

> On Dec 14, 2017, at 4:11 PM, Gary Gregory <garydgreg...@gmail.com> 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
>> 
>> 
>> 
>>> -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 <joerg.schaible@bpm-
>>> 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]

[Gary Gregory]

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) <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
>
>
>
> > -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 <joerg.schaible@bpm-
> > 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]

[Ralph Goers]

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]

[Jörg Schaible]

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