Gary, Let’s start with the easiest first. You have always been more concerned with naming than I have. Whether you call it impl, core, or base would make no difference to me except I see no compelling reason to impact users by changing the name of the dependency. It is one thing to rename variables because you don’t like the names but an entirely different matter when it affects users.
So I am -1 to changing the name. Feel free to modify the documentation but it is pretty hard to not use the word “implementation” when referring to core since it is the main implementation of the Log4j API we provide. Second, my definition of smaller core and yours appear to be different. I have stated numerous times that my goal for 3.0 is to fully support JPMS and that the goal for core is to have it only have hard external dependency on java.base. That will mean moving XML out into its own module. But frankly, I have always hated properties as a format for configuring log4j components. Our configuration is hierarchical in nature while properties are not. Square peg, round hole. To that end I plan on reimplementing the JSON configuration moving the JsonReader from Json Template Layout into core and using that to parse a JSON configuration. So that will leave core with two out-of-the-box configuration formats, one of which is doesn’t drive me nuts. As for using system properties for configuration. No. We use system properties to modify behavior of internal components and to restrict the use of components that should not be given free reign just because they are on the class path.That is completely different from configuring logging and would create a mess. As for plugins, there is no way 3.0 won’t have them by default. Without plugins you would be forced back to using Java class names everywhere and all the Lookups and Pattern Converters would have to be hard-wired into their respective owners. IMO, that is a step back. In short, while Log4j 3.0 will impact users in some ways the goal must be that users can simply change the log4j version number and add dependencies for optional components they want to use and add system properties for optional components they want to enable. They must not be forced to change their configuration files in any way. They MUST NOT be forced to recompile as that could mean that they could only use dependencies compatible with Log4j 3.0. The one case where users may be forced to recompile is for JPMS support. Access to plugins in other modules requires requires those plugins be recompiled using the 3.0 annotation processor. Note that this would be worse without the plugin system as every log4j component defined in other jars would have to specifically be made open to log4j-core. With the annotation processor users don’t have to do anything except add provides org.apache.logging.log4j.plugins.processor.PluginService with … to their module-info.java file. Ideally, I’d love to find a way to automate that too. Ralph > On Jan 26, 2022, at 6:07 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
