I doubt a majority of the external plugins would work against `3.x`. I raised this issue on July 25th <https://lists.apache.org/thread/fbkc24gp3sfzssqp6mvq62pb3qny1p1y>, though I didn't get any reactions.
On Mon, Oct 9, 2023 at 8:57 PM Ralph Goers <ralph.go...@dslextreme.com> wrote: > I think you are on the right track. We have to think of the main use case > where a break in compatibility would cause a problem - an application uses > libraries compiled with Log4j 2.x. > > I am much less concerned about custom plugins as presumably the user has > some control over them. That said, I would hope the vast majority of > plugins from third parties would continue to work. > > We cannot put users in a position where they cannot upgrade until all > their dependencies do. > > Note that Spring Boot builds with Log4j 2.x. It needs access to > PerformanceSensitive, PropertiesUtil, and PropertySource. > > Ralph > > > On Oct 9, 2023, at 1:17 AM, Piotr P. Karwasz <piotr.karw...@gmail.com> > wrote: > > > > Hi all, > > > > We have often declared that 3.x will **not** constitute a major > > version for Log4j API and that everything that used to work with 2.x > > will work with 3.x (even provider code). > > > > However that statement does not apply in practice, since some breaking > > changes **were** introduced e.g. in the `util` subpackage (cf. [1] > > e.g.), which is marked as internal, but: > > * in practice it is often used by plugin providers, > > * has some classes (like MessageSupplier) that are actually used by > > consumers of the API. > > > > That is why I would propose to revise the statement about compatibility: > > * the main,`message` and `status` packages should be 100% compatible > > with the previous version, > > * the `spi` package should be as much compatible as possible, > > * the `simple` package should be internal and we can do with it > > anything we please, > > * the `util` package should keep the types used by other packages and > > all other classes should be moved to `util.internal`. > > > > I made an experiment[2] to see how many classes we need to keep in > > `util`. It turns out we just need to keep: > > * BiConsumer, IndexedReadOnlyStringMap, MessageSupplier, > > MultiFormatStringBuilderFormattable, ReadOnlyStringMap, > > StringBuilderFormattable, Supplier and TriConsumer to prevent breaking > > changes in the main and `message` packages, > > * StringMap to prevent changes in the `spi` package, > > * we could keep `Constants` to prevent some `2.x` plugins from breaking. > > > > What do you think? > > > > Piotr > > > > [1] https://github.com/apache/logging-log4j2/pull/1586 > > [2] https://github.com/ppkarwasz/logging-log4j2/tree/clean-break > >
