You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@logging.apache.org by gg...@apache.org on 2022/01/15 23:45:52 UTC

[logging-log4j2] branch release-2.x updated (1a9c04f -> 645a06d)

This is an automated email from the ASF dual-hosted git repository.

ggregory pushed a change to branch release-2.x
in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git.


    from 1a9c04f  Add Interpolator#getDefaultLookup().
     new d402f36  Add PropertiesLookup#getProperties().
     new 645a06d  Add PropertiesLookup#getProperties().

The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 .../log4j/core/lookup/PropertiesLookup.java        | 19 ++++++++++++++++---
 ...ntLookupTest.java => PropertiesLookupTest.java} | 22 +++++++++++++---------
 2 files changed, 29 insertions(+), 12 deletions(-)
 copy log4j-core/src/test/java/org/apache/logging/log4j/core/lookup/{EnvironmentLookupTest.java => PropertiesLookupTest.java} (70%)

[logging-log4j2] 02/02: Add PropertiesLookup#getProperties().

Posted by gg...@apache.org.
This is an automated email from the ASF dual-hosted git repository.

ggregory pushed a commit to branch release-2.x
in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git

commit 645a06d3204ccbb56e6f6c6ce0c9356ba2ffce24
Author: Gary Gregory <ga...@gmail.com>
AuthorDate: Sat Jan 15 18:45:48 2022 -0500

    Add PropertiesLookup#getProperties().
    
    Commit 2/2 for cherry-picking to master.
---
 .../log4j/core/lookup/PropertiesLookupTest.java    | 37 ++++++++++++++++++++++
 1 file changed, 37 insertions(+)

diff --git a/log4j-core/src/test/java/org/apache/logging/log4j/core/lookup/PropertiesLookupTest.java b/log4j-core/src/test/java/org/apache/logging/log4j/core/lookup/PropertiesLookupTest.java
new file mode 100644
index 0000000..2c708f0
--- /dev/null
+++ b/log4j-core/src/test/java/org/apache/logging/log4j/core/lookup/PropertiesLookupTest.java
@@ -0,0 +1,37 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache license, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ *      http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the license for the specific language governing permissions and
+ * limitations under the license.
+ */
+
+package org.apache.logging.log4j.core.lookup;
+
+import static org.junit.Assert.assertEquals;
+
+import java.util.HashMap;
+
+import org.junit.jupiter.api.Test;
+
+/**
+ * Tests {@link PropertiesLookup}.
+ */
+public class PropertiesLookupTest {
+
+    @Test
+    public void testGetProperties() {
+        final HashMap<String, String> properties = new HashMap<>();
+        properties.put("A", "1");
+        assertEquals(properties, new PropertiesLookup(properties).getProperties());
+    }
+}

Re: [logging-log4j2] 01/02: Add PropertiesLookup#getProperties().

Posted by Carter Kozak <ck...@ckozak.net>.
Thanks Gary, I appreciate the context, though I admit I still don't understand how it relates directly to the new getter method.

Ralph, I think your question is about the distinction between MapLookup and the new PropertiesLookup that I added recently.
The story begins here: https://github.com/apache/logging-log4j2/pull/646 A reasonable request, it should be possible to load a field from a map-message using '${map:myField}' even if there's a '<Property name="myField">value</Property>' defined in the configuration. Previously we would read the properties map first, then map messages. However, if we simply made that change as is, the default lookup (no prefix) would also have preferred map-message data, potentially from user-input, over the properties that they referenced. Similar issues existed for the subtypes of MapLookup, of which there were a few.
By using a different kind of lookup which isn't aware of MapMessages as the default resolved, we avoid this class of issues, thus the new type. Added here: https://github.com/apache/logging-log4j2/pull/647



On Thu, Jan 20, 2022, at 09:22, Ralph Goers wrote:
> It still isn’t clear to me why the existing lookups aren’t sufficient. I thought we already have a lookup that does the same thing.
> 
> Ralph
> 
> > On Jan 20, 2022, at 5:48 AM, Gary Gregory <ga...@gmail.com> wrote:
> > 
> > Hi Carter,
> > 
> > I have several needs I am trying to satisfy. I have a lot of customizations
> > I have to support and implement in Log4j 1 and 2 (the Log4j 1 code is being
> > migrated to Log4j 2, but we still need to use the bridge to support Log4j 1
> > in 3rd party dependencies and transitive dependencies). We have new apps,
> > we have legacy apps, we have a lot of code. We do a lot of what I would
> > call in-flight manipulation of Log4j 1 and 2 in these apps, and some plain
> > old [re]configurations using the Configurator APIs, which are the easy use
> > cases to implement and support. Users (devs and admins really) can change
> > the Log4j configuration file and have Log4j monitor the file and that's
> > fine, but that's the advanced case because people can too easily muck up
> > these configuration files. Instead of mucking with files, these app servers
> > come up, stay up, and need to be configured and reconfigured through a set
> > of (REST) admin APIs. Some of these admin tasks do all sorts of
> > introspections and reconfigurations and that is where this kind of API
> > comes in. I want to be able to start from something like an Interpolator
> > (in all these code bases, we use the Log4j Interpolator, Commons Lang,
> > Common Text, you name it, it's in some code base somewhere), find this or
> > that StrLookup and returns pieces of it to client, so a UI can say "You're
> > got this config setting, would you like to change it?". Depending on the
> > use case, the app, and the server combo, sometimes changing a setting,
> > means the UI generates a new config file and sends it over, sometimes to
> > translates to calling a specific Configurator API like one of the
> > setLevel() APIs, and some other time we query and/or edit objects directly
> > in Log4j and elsewhere. Sorry for the long write up!
> > 
> > Gary
> > 
> >> On Wed, Jan 19, 2022 at 6:32 PM Carter Kozak <ck...@ckozak.net> wrote:
> >> 
> >> Any chance you could help me understand the rationale for this feature? I
> >> opted not to implement a method akin to MapLookup.getMap because that
> >> wasn't used, avoiding unnecessary API constraints allows us to refactor
> >> more easily in the future. If the values are required elsewhere, it may be
> >> reasonable, but I have another change in flight that may impact such
> >> consumers.
> >> 
> >> Thanks!
> >> -ck
> >> 
> >> On Sat, Jan 15, 2022, at 18:45, ggregory@apache.org wrote:
> >> 
> >> This is an automated email from the ASF dual-hosted git repository.
> >> 
> >> ggregory pushed a commit to branch release-2.x
> >> in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
> >> 
> >> commit d402f360fbad18bc3c0902a65e8e53a1202e57d5
> >> Author: Gary Gregory <ga...@gmail.com>
> >> AuthorDate: Sat Jan 15 18:45:37 2022 -0500
> >> 
> >>    Add PropertiesLookup#getProperties().
> >> 
> >>    Commit 1/2 for cherry-picking to master.
> >> ---
> >> .../logging/log4j/core/lookup/PropertiesLookup.java   | 19
> >> ++++++++++++++++---
> >> 1 file changed, 16 insertions(+), 3 deletions(-)
> >> 
> >> diff --git
> >> a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
> >> b/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
> >> index 995a71b..3066792 100644
> >> ---
> >> a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
> >> +++
> >> b/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
> >> @@ -34,16 +34,28 @@ public final class PropertiesLookup implements
> >> StrLookup {
> >>      */
> >>     private final Map<String, String> properties;
> >> 
> >> +    /**
> >> +     * Constructs a new instance for the given map.
> >> +     *
> >> +     * @param properties map these.
> >> +     */
> >>     public PropertiesLookup(final Map<String, String> properties) {
> >>         this.properties = properties == null
> >>                 ? Collections.emptyMap()
> >>                 : properties;
> >>     }
> >> 
> >> +    /**
> >> +     * Gets the property map.
> >> +     *
> >> +     * @return the property map.
> >> +     */
> >> +    public Map<String, String> getProperties() {
> >> +        return properties;
> >> +    }
> >> +
> >>     @Override
> >> -    public String lookup(
> >> -            @SuppressWarnings("ignored") final LogEvent event,
> >> -            final String key) {
> >> +    public String lookup(@SuppressWarnings("ignored") final LogEvent
> >> event, final String key) {
> >>         return lookup(key);
> >>     }
> >> 
> >> @@ -65,4 +77,5 @@ public final class PropertiesLookup implements StrLookup
> >> {
> >>     public String toString() {
> >>         return "PropertiesLookup{properties=" + properties + '}';
> >>     }
> >> +
> >> }
> >> 
> >> 
> >> 
> 
> 

Re: [logging-log4j2] 01/02: Add PropertiesLookup#getProperties().

Posted by Ralph Goers <ra...@dslextreme.com>.
It still isn’t clear to me why the existing lookups aren’t sufficient. I thought we already have a lookup that does the same thing.

Ralph

> On Jan 20, 2022, at 5:48 AM, Gary Gregory <ga...@gmail.com> wrote:
> 
> Hi Carter,
> 
> I have several needs I am trying to satisfy. I have a lot of customizations
> I have to support and implement in Log4j 1 and 2 (the Log4j 1 code is being
> migrated to Log4j 2, but we still need to use the bridge to support Log4j 1
> in 3rd party dependencies and transitive dependencies). We have new apps,
> we have legacy apps, we have a lot of code. We do a lot of what I would
> call in-flight manipulation of Log4j 1 and 2 in these apps, and some plain
> old [re]configurations using the Configurator APIs, which are the easy use
> cases to implement and support. Users (devs and admins really) can change
> the Log4j configuration file and have Log4j monitor the file and that's
> fine, but that's the advanced case because people can too easily muck up
> these configuration files. Instead of mucking with files, these app servers
> come up, stay up, and need to be configured and reconfigured through a set
> of (REST) admin APIs. Some of these admin tasks do all sorts of
> introspections and reconfigurations and that is where this kind of API
> comes in. I want to be able to start from something like an Interpolator
> (in all these code bases, we use the Log4j Interpolator, Commons Lang,
> Common Text, you name it, it's in some code base somewhere), find this or
> that StrLookup and returns pieces of it to client, so a UI can say "You're
> got this config setting, would you like to change it?". Depending on the
> use case, the app, and the server combo, sometimes changing a setting,
> means the UI generates a new config file and sends it over, sometimes to
> translates to calling a specific Configurator API like one of the
> setLevel() APIs, and some other time we query and/or edit objects directly
> in Log4j and elsewhere. Sorry for the long write up!
> 
> Gary
> 
>> On Wed, Jan 19, 2022 at 6:32 PM Carter Kozak <ck...@ckozak.net> wrote:
>> 
>> Any chance you could help me understand the rationale for this feature? I
>> opted not to implement a method akin to MapLookup.getMap because that
>> wasn't used, avoiding unnecessary API constraints allows us to refactor
>> more easily in the future. If the values are required elsewhere, it may be
>> reasonable, but I have another change in flight that may impact such
>> consumers.
>> 
>> Thanks!
>> -ck
>> 
>> On Sat, Jan 15, 2022, at 18:45, ggregory@apache.org wrote:
>> 
>> This is an automated email from the ASF dual-hosted git repository.
>> 
>> ggregory pushed a commit to branch release-2.x
>> in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
>> 
>> commit d402f360fbad18bc3c0902a65e8e53a1202e57d5
>> Author: Gary Gregory <ga...@gmail.com>
>> AuthorDate: Sat Jan 15 18:45:37 2022 -0500
>> 
>>    Add PropertiesLookup#getProperties().
>> 
>>    Commit 1/2 for cherry-picking to master.
>> ---
>> .../logging/log4j/core/lookup/PropertiesLookup.java   | 19
>> ++++++++++++++++---
>> 1 file changed, 16 insertions(+), 3 deletions(-)
>> 
>> diff --git
>> a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
>> b/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
>> index 995a71b..3066792 100644
>> ---
>> a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
>> +++
>> b/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
>> @@ -34,16 +34,28 @@ public final class PropertiesLookup implements
>> StrLookup {
>>      */
>>     private final Map<String, String> properties;
>> 
>> +    /**
>> +     * Constructs a new instance for the given map.
>> +     *
>> +     * @param properties map these.
>> +     */
>>     public PropertiesLookup(final Map<String, String> properties) {
>>         this.properties = properties == null
>>                 ? Collections.emptyMap()
>>                 : properties;
>>     }
>> 
>> +    /**
>> +     * Gets the property map.
>> +     *
>> +     * @return the property map.
>> +     */
>> +    public Map<String, String> getProperties() {
>> +        return properties;
>> +    }
>> +
>>     @Override
>> -    public String lookup(
>> -            @SuppressWarnings("ignored") final LogEvent event,
>> -            final String key) {
>> +    public String lookup(@SuppressWarnings("ignored") final LogEvent
>> event, final String key) {
>>         return lookup(key);
>>     }
>> 
>> @@ -65,4 +77,5 @@ public final class PropertiesLookup implements StrLookup
>> {
>>     public String toString() {
>>         return "PropertiesLookup{properties=" + properties + '}';
>>     }
>> +
>> }
>> 
>> 
>> 


Re: [logging-log4j2] 01/02: Add PropertiesLookup#getProperties().

Posted by Gary Gregory <ga...@gmail.com>.
Hi Carter,

I have several needs I am trying to satisfy. I have a lot of customizations
I have to support and implement in Log4j 1 and 2 (the Log4j 1 code is being
migrated to Log4j 2, but we still need to use the bridge to support Log4j 1
in 3rd party dependencies and transitive dependencies). We have new apps,
we have legacy apps, we have a lot of code. We do a lot of what I would
call in-flight manipulation of Log4j 1 and 2 in these apps, and some plain
old [re]configurations using the Configurator APIs, which are the easy use
cases to implement and support. Users (devs and admins really) can change
the Log4j configuration file and have Log4j monitor the file and that's
fine, but that's the advanced case because people can too easily muck up
these configuration files. Instead of mucking with files, these app servers
come up, stay up, and need to be configured and reconfigured through a set
of (REST) admin APIs. Some of these admin tasks do all sorts of
introspections and reconfigurations and that is where this kind of API
comes in. I want to be able to start from something like an Interpolator
(in all these code bases, we use the Log4j Interpolator, Commons Lang,
Common Text, you name it, it's in some code base somewhere), find this or
that StrLookup and returns pieces of it to client, so a UI can say "You're
got this config setting, would you like to change it?". Depending on the
use case, the app, and the server combo, sometimes changing a setting,
means the UI generates a new config file and sends it over, sometimes to
translates to calling a specific Configurator API like one of the
setLevel() APIs, and some other time we query and/or edit objects directly
in Log4j and elsewhere. Sorry for the long write up!

Gary

On Wed, Jan 19, 2022 at 6:32 PM Carter Kozak <ck...@ckozak.net> wrote:

> Any chance you could help me understand the rationale for this feature? I
> opted not to implement a method akin to MapLookup.getMap because that
> wasn't used, avoiding unnecessary API constraints allows us to refactor
> more easily in the future. If the values are required elsewhere, it may be
> reasonable, but I have another change in flight that may impact such
> consumers.
>
> Thanks!
> -ck
>
> On Sat, Jan 15, 2022, at 18:45, ggregory@apache.org wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> ggregory pushed a commit to branch release-2.x
> in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
>
> commit d402f360fbad18bc3c0902a65e8e53a1202e57d5
> Author: Gary Gregory <ga...@gmail.com>
> AuthorDate: Sat Jan 15 18:45:37 2022 -0500
>
>     Add PropertiesLookup#getProperties().
>
>     Commit 1/2 for cherry-picking to master.
> ---
> .../logging/log4j/core/lookup/PropertiesLookup.java   | 19
> ++++++++++++++++---
> 1 file changed, 16 insertions(+), 3 deletions(-)
>
> diff --git
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
> index 995a71b..3066792 100644
> ---
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
> +++
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
> @@ -34,16 +34,28 @@ public final class PropertiesLookup implements
> StrLookup {
>       */
>      private final Map<String, String> properties;
>
> +    /**
> +     * Constructs a new instance for the given map.
> +     *
> +     * @param properties map these.
> +     */
>      public PropertiesLookup(final Map<String, String> properties) {
>          this.properties = properties == null
>                  ? Collections.emptyMap()
>                  : properties;
>      }
>
> +    /**
> +     * Gets the property map.
> +     *
> +     * @return the property map.
> +     */
> +    public Map<String, String> getProperties() {
> +        return properties;
> +    }
> +
>      @Override
> -    public String lookup(
> -            @SuppressWarnings("ignored") final LogEvent event,
> -            final String key) {
> +    public String lookup(@SuppressWarnings("ignored") final LogEvent
> event, final String key) {
>          return lookup(key);
>      }
>
> @@ -65,4 +77,5 @@ public final class PropertiesLookup implements StrLookup
> {
>      public String toString() {
>          return "PropertiesLookup{properties=" + properties + '}';
>      }
> +
> }
>
>
>

Re: [logging-log4j2] 01/02: Add PropertiesLookup#getProperties().

Posted by Carter Kozak <ck...@ckozak.net>.
Any chance you could help me understand the rationale for this feature? I opted not to implement a method akin to MapLookup.getMap because that wasn't used, avoiding unnecessary API constraints allows us to refactor more easily in the future. If the values are required elsewhere, it may be reasonable, but I have another change in flight that may impact such consumers.

Thanks!
-ck

On Sat, Jan 15, 2022, at 18:45, ggregory@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
> 
> ggregory pushed a commit to branch release-2.x
> in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
> 
> commit d402f360fbad18bc3c0902a65e8e53a1202e57d5
> Author: Gary Gregory <ga...@gmail.com>
> AuthorDate: Sat Jan 15 18:45:37 2022 -0500
> 
>     Add PropertiesLookup#getProperties().
>     
>     Commit 1/2 for cherry-picking to master.
> ---
> .../logging/log4j/core/lookup/PropertiesLookup.java   | 19 ++++++++++++++++---
> 1 file changed, 16 insertions(+), 3 deletions(-)
> 
> diff --git a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java b/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
> index 995a71b..3066792 100644
> --- a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
> +++ b/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
> @@ -34,16 +34,28 @@ public final class PropertiesLookup implements StrLookup {
>       */
>      private final Map<String, String> properties;
>  
> +    /**
> +     * Constructs a new instance for the given map.
> +     *
> +     * @param properties map these.
> +     */
>      public PropertiesLookup(final Map<String, String> properties) {
>          this.properties = properties == null
>                  ? Collections.emptyMap()
>                  : properties;
>      }
>  
> +    /**
> +     * Gets the property map.
> +     *
> +     * @return the property map.
> +     */
> +    public Map<String, String> getProperties() {
> +        return properties;
> +    }
> +
>      @Override
> -    public String lookup(
> -            @SuppressWarnings("ignored") final LogEvent event,
> -            final String key) {
> +    public String lookup(@SuppressWarnings("ignored") final LogEvent event, final String key) {
>          return lookup(key);
>      }
>  
> @@ -65,4 +77,5 @@ public final class PropertiesLookup implements StrLookup {
>      public String toString() {
>          return "PropertiesLookup{properties=" + properties + '}';
>      }
> +
> }
> 

[logging-log4j2] 01/02: Add PropertiesLookup#getProperties().

Posted by gg...@apache.org.
This is an automated email from the ASF dual-hosted git repository.

ggregory pushed a commit to branch release-2.x
in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git

commit d402f360fbad18bc3c0902a65e8e53a1202e57d5
Author: Gary Gregory <ga...@gmail.com>
AuthorDate: Sat Jan 15 18:45:37 2022 -0500

    Add PropertiesLookup#getProperties().
    
    Commit 1/2 for cherry-picking to master.
---
 .../logging/log4j/core/lookup/PropertiesLookup.java   | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java b/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
index 995a71b..3066792 100644
--- a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
+++ b/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
@@ -34,16 +34,28 @@ public final class PropertiesLookup implements StrLookup {
      */
     private final Map<String, String> properties;
 
+    /**
+     * Constructs a new instance for the given map.
+     *
+     * @param properties map these.
+     */
     public PropertiesLookup(final Map<String, String> properties) {
         this.properties = properties == null
                 ? Collections.emptyMap()
                 : properties;
     }
 
+    /**
+     * Gets the property map.
+     *
+     * @return the property map.
+     */
+    public Map<String, String> getProperties() {
+        return properties;
+    }
+
     @Override
-    public String lookup(
-            @SuppressWarnings("ignored") final LogEvent event,
-            final String key) {
+    public String lookup(@SuppressWarnings("ignored") final LogEvent event, final String key) {
         return lookup(key);
     }
 
@@ -65,4 +77,5 @@ public final class PropertiesLookup implements StrLookup {
     public String toString() {
         return "PropertiesLookup{properties=" + properties + '}';
     }
+
 }