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
>
>

Reply via email to