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 > > > > > >> > > > > > > > > > > > >
