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`.
* we have a `${date:...}` lookup and a `%d{...}`. Note that
`$${date:...}` and `%d{...}` give the same result in a
`PatternLayout`!
## Equivalent concepts in other frameworks
Spring Boot's equivalent of both `PropertiesUtil` and `Interpolator`
is the single `Environment`[1] concept:
* 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?
[1]
https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/core/env/Environment.html
[2]
https://docs.spring.io/spring-framework/reference/core/beans/dependencies/factory-properties-detailed.html
[3]
https://download.eclipse.org/microprofile/microprofile-config-3.0/microprofile-config-spec-3.0.html#configprovider
