> 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".
>>>>>>>> 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
>>>
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
