Lol. Ok An app running in Java 11. That changes nothing. We can certainly make some incompatible changes but as we have previously discussed some of the things you removed will have to be reverted.
Making Log4J 3 not backward compatible would be a disaster. Ralph > On Apr 18, 2022, at 5:07 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > > "an app > will certainly be able to replace their 2.x jars with 3.x jars and continue > to work" > > Certainly not since 3.x requires Java 11. > > Gary > >> On Mon, Apr 18, 2022, 18:19 Ralph Goers <ralph.go...@dslextreme.com> wrote: >> >> I have no idea what you are referring to. >> >> You are talking about having log4j 2 and log4j 3 jars present in the >> application >> at the same time? You can no more do that than you can have a >> log4j-core.2.17.1 >> jar and a log4j-core-2.17.2 jar on the classpath at the same time. But an >> app >> will certainly be able to replace their 2.x jars with 3.x jars and >> continue to work. >> >> Why would you think you need both versions to be present at the same time? >> >> Ralph >> >>> On Apr 19, 2022, at 12:05 AM, Gary Gregory <garydgreg...@gmail.com> >> wrote: >>> >>> How can they coexist when they use the same package names? This is why I >>> want to use a different package name root for 3.x, like org.apache.log4j3 >>> or something like that. >>> >>> On Mon, Apr 18, 2022, 17:07 Ralph Goers <ralph.go...@dslextreme.com> >> wrote: >>> >>>> Gary, that really doesn’t say anything. 2.x and 3.x are already designed >>>> to be able to coexist. >>>> >>>> Ralph >>>> >>>>> On Apr 18, 2022, at 10:50 PM, Gary Gregory <garydgreg...@gmail.com> >>>> wrote: >>>>> >>>>> For my 2c, the better internals are not going to motivate the majority >> of >>>>> users to update to 3.0, features are. It might be different for plugin >>>>> authors, but how many of those are there? My guess is a minuscule >>>> amount. I >>>>> agree that 2.x should live for a long long time, and should be able to >>>>> coexist with 1.x and 3.x. >>>>> >>>>> Gary >>>>> >>>>> Gary >>>>> >>>>> On Mon, Apr 18, 2022, 14:56 Piotr P. Karwasz <piotr.karw...@gmail.com> >>>>> wrote: >>>>> >>>>>> Hi Volcan, >>>>>> >>>>>> On Sun, 17 Apr 2022 at 22:42, Volkan Yazıcı <vol...@yazi.ci> wrote: >>>>>> >>>>>>> 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. >>>>>>> >>>>>> >>>>>> Maybe this can be solved in other ways. For example we could have a: >>>>>> 1. `SerializerFactory` with multiple implementations each one in a >>>> separate >>>>>> module, >>>>>> 2. You use the `ServiceLoaderUtil` to find an implementation or you >> use >>>> the >>>>>> internal one if there are none. >>>>>> >>>>>> I think that the dependency injector is a feature that should stay in >>>> 3.0 >>>>>> to motivate people to move from 2.x. >>>>>> >>>>>> Piotr >>>>>> >>>> >>>> >> >> >>
