> On Jul 15, 2024, at 6:30 AM, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote:
>
> Since the creation of Log4j 2, the concepts of `PropertySource` and
> `StrLookup` and the concepts of `StrLookup` and
> `LogEventPatternConverter` have strongly converged to each other.
> We might consider removing some of them in Log4j Core 4.
>
> ## Problem
>
> Log4j Core uses multiple map-like abstractions that evaluate strings:
>
> * `PropertySource`s are used to provide additional sources of
> **externalized configuration** to
> `PropertiesUtil/PropertyEnvironment`, which is used to modify default
> values of Log4j components.
> * `StrLookup`s are used by `Interpolator` to interpolate the
> attributes of the configuration file, which is something a
> `PropertiesUtil/PropertyEnvironment` could also do.
> The `Interpolator` is also used at runtime by `PatternLayout` to
> format log events.
> * `LogEventPatternConverter`s, which are used by `PatternLayout` to
> format log events.
>
> Since the domains of these abstractions overlap, we end up
> implementing these in pairs. For example:
>
> * we have a `SpringLookup` and a `SpringPropertySource`.
SpringLookup returns the value of a key. A property source locates a set of
keys. So comparing them is apples to oranges. Or rather - an apple to a bushel
of apples. PropertySources are NOT available to the logging configuration.
However, a Lookup can certainly use a ProeprtySource to locate the keys it is
to resolve.
> * we have a `${date:...}` lookup and a `%d{...}`. Note that
> `$${date:...}` and `%d{...}` give the same result in a
> `PatternLayout`!
While they do in the Layout they do not have the same behavior when used in the
FilePattern on a Rolling Appender. IMO, it was a poor decision to use the data
in the file pattern to determine the rollover interval.
>
> ## Equivalent concepts in other frameworks
>
> Spring Boot's equivalent of both `PropertiesUtil` and `Interpolator`
> is the single `Environment`[1] concept:
However, Spring’s variables are primarily used while configuring the
application. The same is true with PropertySources. OTOH Lookups are meant to
be used while the application is running.
>
> * The `Environment` provides default values of Spring Boot beans, like
> `PropertiesUtil` does.
> * `${name}` expressions can be used in XML bean definitions[2], which
> is the concept that resembles our configuration file.
>
> If `${name}` expressions are too restrictive (e.g. you can use them to
> get the current date), SpEL expressions can be used. Therefore SpEL
> expressions ressemble the way we use pattern converters.
>
> The Jakarta world also released a `Config`[3] concept, which works
> pretty much like Spring's `Environment`.
>
> ## Possible solutions
>
> For Log4j 4 we could consider:
>
> * removing the `StrLookup` concept and provide a simple `Interpolator`
> that uses `PropertiesUtil`.
> * make both `PropertiesUtil` and `StrSubstitutor` pluggable: external
> frameworks might want to replace our implementations of these
> components entirely with their own implementations.
> * enhance the few configuration attributes that accept lazy lookups to
> accept `PatternLayout` patterns instead.
>
> What do you think?
I am not convinced.
The advantage with Lookups is that they can be namespaced. i.e. ${ctx:myKey}.
This is a nice short way of expressing which Map you want to look in.
Specifying ${myKey} would require merging all the Maps together.
I am not a fan of making either of these pluggable. Making StrSubstitutor
pluggable is a security risk. PropertiesUtil is pluggable by way of custom
PropertySources.
Compared to a Lookup a PatternConverter is fairly expensive. A Lookup simply
returns the value of a key from a Map. OTOH a PatternConverter is really a
formatter. Granted we do have things like the upper Lookup that acts as a
formatter but its capabilities are purposefully limited.
Ralph
