See below. > On Apr 18, 2022, at 8:29 PM, Volkan Yazıcı <vol...@yazi.ci> wrote: > > On Mon, Apr 18, 2022 at 10:17 AM Ralph Goers <ralph.go...@dslextreme.com > <mailto: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. >
You will have to be more specific. I know ConstraintValidators are in 2.x and I know that they validate plugin parameters. There are extra features planned for 3.x. But when you imply that they aren’t working 2.x I have no idea what you are talking about. But no, PluginManager doesn’t know about them as they are implemented in the visitor. Why is that a problem? > >>> 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. Yes, it will be resolved in 3.x. There is already a workaround people are using for 2.x. > > >>> 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"*. I added the ServiceLoader support for Plugins in 3.x because it is required for JPMS. I made it as backward compatible as possible My objections are: 1. I want to get 3.x done. The more we try to enhance 2.x the less focus we have on that. 2. I want people to have a compelling reason to switch to 3.x. Migrating features back to 2.x limits the value of 3.x. 3. While we hope the changes in 3.x are indeed backward compatible it has yet to be proven they are. At this point in the life of 2.x I don’t want to introduce any significant risk of breakage. Ralph
