More than that, it has already taken too long. I’d like to support Java 11 fully.
Ralph > On Jan 28, 2022, at 9:25 AM, Matt Sicker <[email protected]> wrote: > > 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 <[email protected]> wrote: >> >> What is the rush for releasing version 3? >> >> Gary >> >> On Fri, Jan 28, 2022, 10:05 Volkan Yazıcı <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>> wrote: >>>>> >>>>> On Wed, Jan 26, 2022 at 7:44 PM Carter Kozak <[email protected]> >>> 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 <[email protected]> >>> 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 < >>>> [email protected]> >>>>>> 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 >>>>>>>>> >>>>>>> >>>>>> >>>> >>> >
