commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Tompkins <chtom...@gmail.com>
Subject Re: [text] Adapt the Log4j 2 Interpolator to [text]
Date Sun, 11 Feb 2018 18:38:11 GMT


> On Feb 11, 2018, at 1:24 PM, Gary Gregory <garydgregory@gmail.com> wrote:
> 
> On Sun, Feb 11, 2018 at 11:10 AM, Gary Gregory <garydgregory@gmail.com>
> wrote:
> 
>> On Sun, Feb 11, 2018 at 4:40 AM, Pascal Schumacher <
>> pascalschumacher@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 <garydgregory@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 <chtompki@gmail.com>
>>>>> wrote:
>>>>> 
>>>>> 
>>>>>> On Dec 14, 2017, at 4:11 PM, Gary Gregory <garydgregory@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) <
>>>>>>> apache@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.goers@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-unsubscribe@commons.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> ------------------------------------------------------------
>>>>>>>>> ---------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> ------------------------------------------------------------
>>>>>>>> ---------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>> 
>>>>>>>> 
>>>>>>>> ------------------------------------------------------------
>>>>>> ---------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>> 
>>>>>> 
>>>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>> 
>>> 
>> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message