I’d imagine it’s because maintaining two active development branches for a long time is a pain in the ass. — Matt Sicker
> On Jan 28, 2022, at 10:15, Gary Gregory <garydgreg...@gmail.com> wrote: > > What is the rush for releasing version 3? > > Gary > > On Fri, Jan 28, 2022, 10:05 Volkan Yazıcı <vol...@yazi.ci> wrote: > >> I think such an SPI effort will not add a value enough to justify the delay >> it will cause for 3.0.0. We need to release `master`, preferably, ASAP, >> IMHO. Any "enhancements" can be scheduled for later releases, including >> 4.0.0. >> >> For the record, I second Ralph's idea of pulling JsonReader up from >> JsonTemplateLayout and natively support properties+JSON in the core. >> >> On Thu, Jan 27, 2022 at 9:08 PM Matt Sicker <boa...@gmail.com> wrote: >> >>> Defining an appropriate SPI in log4j-plugins for how to transform a >>> configuration source into a configuration instance seems like a good >>> idea. Some of my earlier ideas on the DI SPI was to allow for >>> alternative implementations that were either generated code or >>> hand-written code to avoid runtime reflection or to allow for a >>> statically defined configuration. >>> >>> On Thu, Jan 27, 2022 at 7:37 AM Gary Gregory <garydgreg...@gmail.com> >>> wrote: >>>> >>>> On Wed, Jan 26, 2022 at 7:44 PM Carter Kozak <cko...@ckozak.net> >> wrote: >>>> >>>>> If the API is a minimal core, that sounds like a bug! However, I >> don't >>>>> think that's quite the case, it requires that the consumer implement >>> their >>>>> own loggers entirely. What I'm thinking about is more of an >>>>> spi/implementation separation akin to our loggers, but for >> transforming >>>>> configuration bytes into a log4j configuration. >>>>> >>>> >>>> I thought that was the point of splitting out a log4j-plugins module, >> but >>>> maybe that's wishful thinking on my part. >>>> >>>> Gary >>>> >>>>> >>>>> -ck >>>>> >>>>> On Wed, Jan 26, 2022, at 19:38, Matt Sicker wrote: >>>>>> A truly minimal core that only supports properties is the API >> itself. >>>>> Look into SimpleLogger. >>>>>> >>>>>> — >>>>>> Matt Sicker >>>>>> >>>>>>> On Jan 26, 2022, at 18:29, Carter Kozak <cko...@ckozak.net> >> wrote: >>>>>>> >>>>>>> I agree with Gary about a truly minimal core (though I'm going >> to >>>>> stay out of the naming argument, it's one of the two hardest problems >>> in >>>>> CS). My largest use-case doesn't involve parsing any sort of >>> configuration >>>>> -- it's all programmatic. I'd benefit from the ability to run without >>> any >>>>> sort of DI, plugin system, or configuration parser. >>>>>>> >>>>>>> -ck >>>>>>> >>>>>>>> On Wed, Jan 26, 2022, at 18:50, Matt Sicker wrote: >>>>>>>> I'm not a fan of the properties format for the same reasons as >>> Ralph. >>>>>>>> I think we should try to support a structured format like JSON >> by >>>>>>>> default as a JSON parser is fairly small to define when you >> don't >>> need >>>>>>>> fancy annotation-related features. >>>>>>>> >>>>>>>> The plugins module might seem heavy, but the large number of >>>>>>>> additional lines of code that would be necessary in every plugin >>> to do >>>>>>>> all the same boilerplate would likely be far greater than the >>> plugin >>>>>>>> system. Just think of all the string conversion, null checks, >>> empty >>>>>>>> checks, deprecated static factory methods, and config files that >>> would >>>>>>>> end up looking like Spring beans.xml files, if the plugin system >>>>>>>> didn't exist. This would just be thousands more lines for >>>>>>>> auto-formatters to have fun with. >>>>>>>> >>>>>>>> While it'd be neat to just reuse another dependency for >>> configuration >>>>>>>> and dependency injection, what logging framework would that >>> dependency >>>>>>>> use? Also, any off-the-shelf DI framework will have far more >>> features >>>>>>>> than we need to parse a config file and create its graph of >>> objects. >>>>>>>> If there were something like a pico-guice type framework that we >>> could >>>>>>>> copy into the library like picocli, then that would be another >>> story. >>>>>>>> >>>>>>>>> On Wed, Jan 26, 2022 at 7:08 AM Gary Gregory < >>> garydgreg...@gmail.com> >>>>> wrote: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Is a truly small core possible for 3.0? >>>>>>>>> >>>>>>>>> What I mean by that is that I'd like to run an app with log4j >>>>> without an >>>>>>>>> XML configuration, or JSON, or YAML, or the whole plugin >>>>> infrastructure, >>>>>>>>> scanning, or reading a plugin metadata db. Just a properties >>> files. >>>>> And if >>>>>>>>> I can only run with just a properties file, I should be able to >>> run >>>>> only >>>>>>>>> with system properties. >>>>>>>>> >>>>>>>>> With the addition in master of a separate log4j-plugins module, >>> on >>>>> top of >>>>>>>>> log4j-core, 3.0 is feeling heavier and heavier, an so >>> complicated. >>>>>>>>> >>>>>>>>> I am not an fan of inventing a whole configuration and plugin >>>>> system, I'd >>>>>>>>> rather depend one even if it is copying it. It just feels like >>>>>>>>> not-invented-here syndrome. >>>>>>>>> >>>>>>>>> As an aside, I have never liked that we have a jar called >>> log4j-core >>>>> but on >>>>>>>>> the web site it's called "Log4j Implementation", it's >> confusing. >>>>>>>>> >>>>>>>>> For 3.0, it would be nice to make it obvious that what depends >> on >>>>> java.base >>>>>>>>> be in a module called log4j-base instead of core. >>>>>>>>> >>>>>>>>> Gary >>>>>>>> >>>>>> >>>>> >>> >>
