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
>>
>>
>

Reply via email to