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

Reply via email to