I’ll note one design constraint behind property sources and lookups. Property
sources are defined in the API while lookups are defined in Core. Besides that,
property sources are intended for use with configuration (either for components
outside the config file or for reuse in a config file) while lookups are
intended for use with log events, though the ability to use properties in log
events makes this confusing.
> On Jul 15, 2024, at 08:30, 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`.
> * 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
