On the idea of an SPI for configuration, I think that’s a great idea. There’s a bit of that which could form its own module.
— Matt Sicker > On Jan 26, 2022, at 18:44, 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. > > -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 >>>> >>
