Yesterday, I spent some time porting the general logic from Feather (along with re-adding a “ReifiedType” class similar to the “TypeReference” class in Guice) along with filling in the functionality gaps it had which I already had support for in the BeanManager API (mainly support for @Inject-annotated methods which is fairly 3.x-specific as 2.x only injects config data into fields and static factory methods). I’ve pushed some work in progress to a fork to avoid generating a ton of mailing list traffic (which as of now is +969,-4956 lines, though of course a large number of those lines are license headers due to the BeanManager implementation being split into several small classes) [1]. So far, it seems fairly promising, especially in being a bit easier to use and understand how it works. I’ll be working on a wiki doc in Confluence to describe a higher level proposal around where this is going, though I’m still playing around with the new Injector code before I know more on how this proposal will look.
[1]: https://github.com/apache/logging-log4j2/compare/master...jvz:di?expand=1 — Matt Sicker > On Jan 29, 2022, at 07:33, Gary Gregory <garydgreg...@gmail.com> wrote: > > 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 >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>> >>> >> >>
