I’ve recently been looking at a super small DI library [1] which might be more useful as a basis for the new DI system. If this logic is adaptable enough, this could form the basis for a sort of pico-dependency-injection kernel. The current code in master is more inspired by CDI which is a bit heavier which may not be necessary. I’ll experiment with that a bit and see where it goes.
[1]: https://github.com/zsoltherpai/feather — Matt Sicker > On Jan 28, 2022, at 11:33, Ralph Goers <[email protected]> wrote: > > 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 >>>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >> >
