> On May 12, 2022, at 10:15 AM, Chris Hegarty <[email protected]> wrote:
>
>
> My motivation for bringing this up now is just to explicitly highlight the
> consequences and potential wide impact of such a change, not to make any
> concrete suggestions. It's a difficult balancing act to weigh compatibility
> against making progress, but ultimately j.u.f.Supplier is the right choice
> (there are just different ways to get there).
Any ideas on how to get there? The one proposal Gary made was to require log4j3
artifacts and renaming all packages to org.apache.logging.log4j3. The
consequences of this would be:
a. Both are on the classpath - unless we change log4j2.xml to log4j3.xml and
change all our property names then both will try to load the same logging
configuration, which is bound to be problematic.
b. We create a bridge in log4j3 for the log4j 2 api. I just see this as a mess
and confusing to users.
FWIW, the impact of us using our own Supplier seems non-existent since anyone
using those methods would be providing a lambda expression.
Ralph
