I think doing some inversion of control is likely sufficient here. That would entail some sort of interfaces in Core which are implemented by the Async code. What that looks like, I’m not sure, but it’s a common problem to solve.
> On Jul 7, 2023, at 2:44 PM, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > Hi Remko, > > On Thu, 29 Jun 2023 at 14:04, Remko Popma <remko.po...@gmail.com> wrote: >> >>> 1. Configuration has properties related to async logging: >> `asyncLoggerConfigDelegate` and `asyncWaitStrategyFactory`. These >> should be removed before the split, but I don't know what would be the >> right way to do it. >> >> How would that work? >> Will Log4j 3 configurations be incompatible with Log4j 2 configurations? >> (Remember we had many complaints about that from users migrating from 1 to >> 2…) >> >> Shouldn’t this be such that a configuration containing Async elements only >> works when the Async module is in the classpath? >> (Which begs the question: how should it fail when this isn’t the case? >> Ideally give a helpful error message specifying how users can fix the >> problem.) > > I think it could work the same way as with a missing `log4j-jdbc` or > `log4j-smtp`: `AsyncLoggerConfig` and `AsyncWaitStrategyFactoryConfig` > are plugins, the DI system will warn users if it does not know such > plugins. > > The tricky part is to modify `AbstractConfiguration` to accept any > reasonable plugin as a direct subcomponent. We could either: > > * do what was done in `log4j-script`: we leave enough interfaces in > `log4j-core` so that we can keep async-specific stuff in > `AbstractConfiguration`, > * or solve this in a more general way by introducing a marker > `ConfigurationExtension` interface and allow all plugins that > implement it to be direct children of the configuration. > > Piotr
