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 <garydgreg...@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 <cko...@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, ggreg...@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 <garydgreg...@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 + '}'; > >> } > >> + > >> } > >> > >> > >> > >
