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
