Thanks for raising this subject Matt, I am certainly interested in porting
the plugin system in 3.x to 2.x for a very simple reason: because plugins
are broken in 2.x. Let me elaborate on this and some more:

   1. I was working on LOG4J2-3082 (support external serializers, e.g.,
   Jackson, in JTL) and there I needed `@RequiredClass`. Ralph already
   implemented this in `master`, I just need to copy it to `release-2.x`,
   after all it is just a `@ConstraintValidator`, right? Right... But it
   simply won't work. Because JTL, as `PatternLayout`, uses `PluginManager` to
   load plugins and that doesn't support `@ConstraintValidator` et al.?! I've
   discussed this with Matt and we came to the conclusion that porting the new
   plugin infra from 3.x to 2.x is easier compared to fixing the problem in
   2.x.
   2. 3.x plugins use `ServiceLoader`, which doesn't suffer from problems
   (e.g., maven-flattening issues) 2.x does.
   3. 3.x plugins are backward-compatible, i.e., they support 2.x plugins.
   4. Plugin refactoring is one of the most important changes in 3.x. By
   porting this to 2.x, we will be testing it earlier and zeroing the chances
   of a surprise in the domain of plugins while migrating from 2.x to 3.x.
   5. 2.x is here to stay, probably for decades.

Regarding the *"I can start using the plugins package inside core in 2.x so
it’s the same package name as in 3.x"* option, I'd indeed prefer that.
Though let's first have a resolution on whether to proceed or not.

On Sat, Apr 16, 2022 at 7:15 PM Matt Sicker <boa...@gmail.com> wrote:

> Hey all, I’m considering porting the new DI system back to 2.x (but put
> all in core as there’s no plugins module there) as there seems to be
> interest in using this earlier than in 3.0. While I’d be willing to do
> this, I wanted to see what anyone else thinks about the idea. I’d likely
> begin on a branch or fork, so it’d be nice to get another 2.17.x release
> out before I merged anything about this.
>
> Only real disadvantage of doing this is that the packages move around a
> little in 3.x, so I’ll have to add more duplicate annotations in 3.x
> afterwards to maintain compatibility. Although maybe I can start using the
> plugins package inside core in 2.x so it’s the same package name as in 3.x.
>
> —
> Matt Sicker

Reply via email to