Umm, guys. Log4j-plugins doesn’t know what a Configuration is. It has no dependency on log4j-core. So a configuration SPI located there doesn’t make a lot of sense.
In a sense, we already have a configuration SPI. You can use any magic you want to create a tree of Nodes. Once you have that tree you pass it to AbstractConfiguration and it does the rest. That is why it is pretty easy to reate support for any configuration “language” you want. It simply has the downside that a lot of engineers don’t want to interact with Nodes and instead want to interact with the internals of log4j instead. Our current SPI for manipulating Nodes is the ComponentBuilder API. Ralph > On Jan 27, 2022, at 1: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 >>>>>> >>>> >>>
