Those are good points. To me, the fact that 2.x will be around for a long time is one of the main reasons why I even considered this idea. I’d like to hear more from the community first, though.
— Matt Sicker > On Apr 17, 2022, at 15:42, Volkan Yazıcı <vol...@yazi.ci> wrote: > > 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
