On Mon, Apr 18, 2022 at 10:17 AM Ralph Goers <ralph.go...@dslextreme.com> wrote:
> > On Apr 17, 2022, at 10:42 PM, 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. > > @RequiredClass is another feature that was planned for 3.0 so the fact > that it > doesn’t work in 2.x is no great surprise. I did have it working in 3.0 > before the > DI system was integrated so getting it to work in 2.x would be easy. The > DI > system is not required for that. > As I indicated above, I discovered the issue via `@RequiredClass`, it is not the only problem, it is the tip of the iceberg. `PluginManager` simply doesn't take `@ConstraintValidator` et al. into account and `PluginManager` is used in plenty of places. Further, `TypeConverter`s are also a part of the plugin system and they work in a totally different way compared to `PluginManager`. Long story short, the problem is way bigger than `@RequiredClass`. If you think this can be fixed easily without dragging the 3.x plugin infra to 2.x, I am all ears. Also please note that I am not claiming backporting 3.x plugin infra will solve the problem; it will ease the problem and improve the 2.x plugin infra. > > 2. 3.x plugins use `ServiceLoader`, which doesn't suffer from problems > > (e.g., maven-flattening issues) 2.x does. > > Not sure what this has to do with anything. We aren’t migrating the > ServiceLoader plugin implementation back to 2.x. > Remember the Maven Shade Plugin issue due to Log4j 2.x plugins where we decided to not proceed with the idea since 3.x plugin infra will solve that? If we backport 3.x plugin infra to 2.x, 2.x will be migrating to the `ServiceLoader` (granted that backward compatibility with the old `Log4jPlugins.dat` is preserved) and the Maven Shade Plugin issue will be automatically resolved. > > 3. 3.x plugins are backward-compatible, i.e., they support 2.x plugins. > > You mean that the 3.x plugin system supports 2.x plugins. Yes, that was > intentional. 3.x plugins will not work in 2.x. That is intentional. > > > 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. > > -1. Not gonna happen. If we do this then 3.x becomes almost pointless. > AFAIC, the motherships of 3.x are more fine-grained Maven modules and JPMS support. I am struggling to understand your objection here. If 3.x plugin infra is better than the one in 2.x, fixes 2.x problems, is backward compatible, and ready to be voluntarily backported by a PMC member, I simply don't see a problem. Would you mind helping us to understand why you think this is not a good idea and will make 3.x pointless, please? Try to understand my point here, please. Matt and I see a benefit, though you don't agree. This is perfectly fine; not to mention you know the code base better than we do. Please help us to understand rather than simply slamming the door to our face with an *"ain't gonna happen"*. Kind regards.
