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

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

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

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?

Gary
Reply | Threaded
Open this post in threaded view
|

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

Jörg Schaible-5
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Jan Matèrne (jhm)
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:[hidden email]]
> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

garydgregory
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) <[hidden email]>
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:[hidden email]]
> > 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

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

Rob Tompkins


> On Dec 14, 2017, at 4:11 PM, Gary Gregory <[hidden email]> 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) <[hidden email]>
> 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:[hidden email]]
>>> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

garydgregory
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 <[hidden email]> wrote:

>
>
> > On Dec 14, 2017, at 4:11 PM, Gary Gregory <[hidden email]>
> 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) <[hidden email]>
> > 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:[hidden email]]
> >>> 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: [hidden email]
> >>>> For additional commands, e-mail: [hidden email]
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

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

garydgregory
On Sat, Feb 10, 2018 at 12:44 PM, Gary Gregory <[hidden email]>
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 <[hidden email]> wrote:
>
>>
>>
>> > On Dec 14, 2017, at 4:11 PM, Gary Gregory <[hidden email]>
>> 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) <[hidden email]>
>> > 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:[hidden email]]
>> >>> 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: [hidden email]
>> >>>> For additional commands, e-mail: [hidden email]
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: [hidden email]
>> >>> For additional commands, e-mail: [hidden email]
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>
> 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 <[hidden email]> wrote:
>>
>>>
>>>> On Dec 14, 2017, at 4:11 PM, Gary Gregory <[hidden email]>
>>> 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) <[hidden email]>
>>>> 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:[hidden email]]
>>>>>> 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: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

garydgregory
On Sun, Feb 11, 2018 at 4:40 AM, Pascal Schumacher <[hidden email]
> 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 <[hidden email]>
>> 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 <[hidden email]>
>>> wrote:
>>>
>>>
>>>> On Dec 14, 2017, at 4:11 PM, Gary Gregory <[hidden email]>
>>>>>
>>>> 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) <[hidden email]
>>>>> >
>>>>> 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:[hidden email]]
>>>>>>> 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: [hidden email]
>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>>>> ---------
>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

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

garydgregory
On Sun, Feb 11, 2018 at 11:10 AM, Gary Gregory <[hidden email]>
wrote:

> On Sun, Feb 11, 2018 at 4:40 AM, Pascal Schumacher <
> [hidden email]> 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 <[hidden email]>
>>> 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 <[hidden email]>
>>>> wrote:
>>>>
>>>>
>>>>> On Dec 14, 2017, at 4:11 PM, Gary Gregory <[hidden email]>
>>>>>>
>>>>> 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) <
>>>>>> [hidden email]>
>>>>>> 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:[hidden email]]
>>>>>>>> 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: [hidden email]
>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------
>>>>>>>> ---------
>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>>>> ---------
>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>> ---------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

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

Pascal Schumacher
In reply to this post by garydgregory
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Rob Tompkins
In reply to this post by garydgregory


> On Feb 11, 2018, at 1:24 PM, Gary Gregory <[hidden email]> wrote:
>
> On Sun, Feb 11, 2018 at 11:10 AM, Gary Gregory <[hidden email]>
> wrote:
>
>> On Sun, Feb 11, 2018 at 4:40 AM, Pascal Schumacher <
>> [hidden email]> 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 <[hidden email]>
>>>> 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 <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>
>>>>>> On Dec 14, 2017, at 4:11 PM, Gary Gregory <[hidden email]>
>>>>>>>
>>>>>> 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) <
>>>>>>> [hidden email]>
>>>>>>> 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:[hidden email]]
>>>>>>>>> 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: [hidden email]
>>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------
>>>>>>>>> ---------
>>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------
>>>>>>>> ---------
>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------
>>>>>> ---------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Pascal Schumacher
In reply to this post by garydgregory
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

garydgregory
On Sun, Feb 11, 2018 at 12:05 PM, Pascal Schumacher <
[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

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

garydgregory
On Sun, Feb 11, 2018 at 2:46 PM, Gary Gregory <[hidden email]>
wrote:

>
>
> On Sun, Feb 11, 2018 at 12:05 PM, Pascal Schumacher <
> [hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

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

Charles Honton
Definitely create interfaces.

Chas

> On Feb 11, 2018, at 1:57 PM, Gary Gregory <[hidden email]> wrote:
>
> On Sun, Feb 11, 2018 at 2:46 PM, Gary Gregory <[hidden email]>
> wrote:
>
>>
>>
>> On Sun, Feb 11, 2018 at 12:05 PM, Pascal Schumacher <
>> [hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

garydgregory
On Sun, Feb 11, 2018 at 8:12 PM, Chas Honton <[hidden email]> 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 <[hidden email]>
> wrote:
> >
> > On Sun, Feb 11, 2018 at 2:46 PM, Gary Gregory <[hidden email]>
> > wrote:
> >
> >>
> >>
> >> On Sun, Feb 11, 2018 at 12:05 PM, Pascal Schumacher <
> >> [hidden email]> 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: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

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

garydgregory
On Mon, Feb 12, 2018 at 12:30 PM, Pascal Schumacher <
[hidden email]> 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
>
12