Hi Matt,

Thank you for your reply. I agree with all you say. My desire is to offer a
light-weight code path. I don't care about "liking" a format vs. another,
it's just that properties are built in java.base.

Gary

On Wed, Jan 26, 2022 at 6:51 PM Matt Sicker <boa...@gmail.com> 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
>

Reply via email to