That sounds promising Matt, especially considering it also runs on Android.
Gary On Sat, Jan 29, 2022, 00:27 Matt Sicker <boa...@gmail.com> wrote: > 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 <ralph.go...@dslextreme.com> > 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 <boa...@gmail.com> 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 <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 > >>>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>> > >>>> > >> > > > >
