You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Gary Gregory <ga...@gmail.com> on 2022/01/26 13:07:08 UTC
Is a truly small core possible for 3.0?
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
Re: Is a truly small core possible for 3.0?
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ga...@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
Re: Is a truly small core possible for 3.0?
Posted by Gary Gregory <ga...@gmail.com>.
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 <bo...@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 <ga...@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
>
Re: Is a truly small core possible for 3.0?
Posted by Matt Sicker <bo...@gmail.com>.
The StatusLogger class needs a way to work which is via SimpleLogger. This is provided as a fallback option if no providers are found. It’s fairly basic, but you can use it for basic logging.
—
Matt Sicker
> On Jan 26, 2022, at 18:44, Carter Kozak <ck...@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.
>
> -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 <ck...@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 <ga...@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
>>>>
>>
Re: Is a truly small core possible for 3.0?
Posted by Matt Sicker <bo...@gmail.com>.
On the idea of an SPI for configuration, I think that’s a great idea. There’s a bit of that which could form its own module.
—
Matt Sicker
> On Jan 26, 2022, at 18:44, Carter Kozak <ck...@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.
>
> -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 <ck...@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 <ga...@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
>>>>
>>
Re: Is a truly small core possible for 3.0?
Posted by Matt Sicker <bo...@gmail.com>.
Yesterday, I spent some time porting the general logic from Feather (along with re-adding a “ReifiedType” class similar to the “TypeReference” class in Guice) along with filling in the functionality gaps it had which I already had support for in the BeanManager API (mainly support for @Inject-annotated methods which is fairly 3.x-specific as 2.x only injects config data into fields and static factory methods). I’ve pushed some work in progress to a fork to avoid generating a ton of mailing list traffic (which as of now is +969,-4956 lines, though of course a large number of those lines are license headers due to the BeanManager implementation being split into several small classes) [1]. So far, it seems fairly promising, especially in being a bit easier to use and understand how it works. I’ll be working on a wiki doc in Confluence to describe a higher level proposal around where this is going, though I’m still playing around with the new Injector code before I know more on how this proposal will look.
[1]: https://github.com/apache/logging-log4j2/compare/master...jvz:di?expand=1
—
Matt Sicker
> On Jan 29, 2022, at 07:33, Gary Gregory <ga...@gmail.com> wrote:
>
> That sounds promising Matt, especially considering it also runs on Android.
>
> Gary
>
> On Sat, Jan 29, 2022, 00:27 Matt Sicker <bo...@gmail.com> wrote:
>
>> I’ve recently been looking at a super small DI library [1] which might be
>> more useful as a basis for the new DI system. If this logic is adaptable
>> enough, this could form the basis for a sort of pico-dependency-injection
>> kernel. The current code in master is more inspired by CDI which is a bit
>> heavier which may not be necessary. I’ll experiment with that a bit and see
>> where it goes.
>>
>> [1]: https://github.com/zsoltherpai/feather
>> —
>> Matt Sicker
>>
>>> On Jan 28, 2022, at 11:33, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>>
>>> More than that, it has already taken too long. I’d like to support Java
>> 11 fully.
>>>
>>> Ralph
>>>
>>>> On Jan 28, 2022, at 9:25 AM, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>> I’d imagine it’s because maintaining two active development branches
>> for a long time is a pain in the ass.
>>>> —
>>>> Matt Sicker
>>>>
>>>>> On Jan 28, 2022, at 10:15, Gary Gregory <ga...@gmail.com>
>> wrote:
>>>>>
>>>>> What is the rush for releasing version 3?
>>>>>
>>>>> Gary
>>>>>
>>>>> On Fri, Jan 28, 2022, 10:05 Volkan Yazıcı <vo...@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 <bo...@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 <garydgregory@gmail.com
>>>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On Wed, Jan 26, 2022 at 7:44 PM Carter Kozak <ck...@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 <ck...@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 <
>>>>>>> garydgregory@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
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
>>
Re: Is a truly small core possible for 3.0?
Posted by Gary Gregory <ga...@gmail.com>.
That sounds promising Matt, especially considering it also runs on Android.
Gary
On Sat, Jan 29, 2022, 00:27 Matt Sicker <bo...@gmail.com> wrote:
> I’ve recently been looking at a super small DI library [1] which might be
> more useful as a basis for the new DI system. If this logic is adaptable
> enough, this could form the basis for a sort of pico-dependency-injection
> kernel. The current code in master is more inspired by CDI which is a bit
> heavier which may not be necessary. I’ll experiment with that a bit and see
> where it goes.
>
> [1]: https://github.com/zsoltherpai/feather
> —
> Matt Sicker
>
> > On Jan 28, 2022, at 11:33, Ralph Goers <ra...@dslextreme.com>
> wrote:
> >
> > More than that, it has already taken too long. I’d like to support Java
> 11 fully.
> >
> > Ralph
> >
> >> On Jan 28, 2022, at 9:25 AM, Matt Sicker <bo...@gmail.com> wrote:
> >>
> >> I’d imagine it’s because maintaining two active development branches
> for a long time is a pain in the ass.
> >> —
> >> Matt Sicker
> >>
> >>> On Jan 28, 2022, at 10:15, Gary Gregory <ga...@gmail.com>
> wrote:
> >>>
> >>> What is the rush for releasing version 3?
> >>>
> >>> Gary
> >>>
> >>> On Fri, Jan 28, 2022, 10:05 Volkan Yazıcı <vo...@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 <bo...@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 <garydgregory@gmail.com
> >
> >>>>> wrote:
> >>>>>>
> >>>>>> On Wed, Jan 26, 2022 at 7:44 PM Carter Kozak <ck...@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 <ck...@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 <
> >>>>> garydgregory@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
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>>
> >>
> >
>
>
Re: Is a truly small core possible for 3.0?
Posted by Matt Sicker <bo...@gmail.com>.
I’ve recently been looking at a super small DI library [1] which might be more useful as a basis for the new DI system. If this logic is adaptable enough, this could form the basis for a sort of pico-dependency-injection kernel. The current code in master is more inspired by CDI which is a bit heavier which may not be necessary. I’ll experiment with that a bit and see where it goes.
[1]: https://github.com/zsoltherpai/feather
—
Matt Sicker
> On Jan 28, 2022, at 11:33, Ralph Goers <ra...@dslextreme.com> wrote:
>
> More than that, it has already taken too long. I’d like to support Java 11 fully.
>
> Ralph
>
>> On Jan 28, 2022, at 9:25 AM, Matt Sicker <bo...@gmail.com> wrote:
>>
>> I’d imagine it’s because maintaining two active development branches for a long time is a pain in the ass.
>> —
>> Matt Sicker
>>
>>> On Jan 28, 2022, at 10:15, Gary Gregory <ga...@gmail.com> wrote:
>>>
>>> What is the rush for releasing version 3?
>>>
>>> Gary
>>>
>>> On Fri, Jan 28, 2022, 10:05 Volkan Yazıcı <vo...@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 <bo...@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 <ga...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> On Wed, Jan 26, 2022 at 7:44 PM Carter Kozak <ck...@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 <ck...@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 <
>>>>> garydgregory@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
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>
>
Re: Is a truly small core possible for 3.0?
Posted by Ralph Goers <ra...@dslextreme.com>.
More than that, it has already taken too long. I’d like to support Java 11 fully.
Ralph
> On Jan 28, 2022, at 9:25 AM, Matt Sicker <bo...@gmail.com> wrote:
>
> I’d imagine it’s because maintaining two active development branches for a long time is a pain in the ass.
> —
> Matt Sicker
>
>> On Jan 28, 2022, at 10:15, Gary Gregory <ga...@gmail.com> wrote:
>>
>> What is the rush for releasing version 3?
>>
>> Gary
>>
>> On Fri, Jan 28, 2022, 10:05 Volkan Yazıcı <vo...@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 <bo...@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 <ga...@gmail.com>
>>>> wrote:
>>>>>
>>>>> On Wed, Jan 26, 2022 at 7:44 PM Carter Kozak <ck...@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 <ck...@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 <
>>>> garydgregory@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
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>
Re: Is a truly small core possible for 3.0?
Posted by Matt Sicker <bo...@gmail.com>.
I’d imagine it’s because maintaining two active development branches for a long time is a pain in the ass.
—
Matt Sicker
> On Jan 28, 2022, at 10:15, Gary Gregory <ga...@gmail.com> wrote:
>
> What is the rush for releasing version 3?
>
> Gary
>
> On Fri, Jan 28, 2022, 10:05 Volkan Yazıcı <vo...@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 <bo...@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 <ga...@gmail.com>
>>> wrote:
>>>>
>>>> On Wed, Jan 26, 2022 at 7:44 PM Carter Kozak <ck...@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 <ck...@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 <
>>> garydgregory@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
>>>>>>>>
>>>>>>
>>>>>
>>>
>>
Re: Is a truly small core possible for 3.0?
Posted by Gary Gregory <ga...@gmail.com>.
What is the rush for releasing version 3?
Gary
On Fri, Jan 28, 2022, 10:05 Volkan Yazıcı <vo...@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 <bo...@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 <ga...@gmail.com>
> > wrote:
> > >
> > > On Wed, Jan 26, 2022 at 7:44 PM Carter Kozak <ck...@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 <ck...@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 <
> > garydgregory@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
> > > > > >>
> > > > >
> > > >
> >
>
Re: Is a truly small core possible for 3.0?
Posted by Volkan Yazıcı <vo...@yazi.ci>.
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 <bo...@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 <ga...@gmail.com>
> wrote:
> >
> > On Wed, Jan 26, 2022 at 7:44 PM Carter Kozak <ck...@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 <ck...@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 <
> garydgregory@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
> > > > >>
> > > >
> > >
>
Re: Is a truly small core possible for 3.0?
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <bo...@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 <ga...@gmail.com> wrote:
>>
>> On Wed, Jan 26, 2022 at 7:44 PM Carter Kozak <ck...@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 <ck...@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 <ga...@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
>>>>>>
>>>>
>>>
Re: Is a truly small core possible for 3.0?
Posted by Matt Sicker <bo...@gmail.com>.
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 <ga...@gmail.com> wrote:
>
> On Wed, Jan 26, 2022 at 7:44 PM Carter Kozak <ck...@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 <ck...@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 <ga...@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
> > > >>
> > >
> >
Re: Is a truly small core possible for 3.0?
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Jan 26, 2022 at 7:44 PM Carter Kozak <ck...@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 <ck...@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 <ga...@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
> > >>
> >
>
Re: Is a truly small core possible for 3.0?
Posted by Carter Kozak <ck...@ckozak.net>.
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.
-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 <ck...@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 <ga...@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
> >>
>
Re: Is a truly small core possible for 3.0?
Posted by Matt Sicker <bo...@gmail.com>.
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 <ck...@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 <ga...@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
>>
Re: Is a truly small core possible for 3.0?
Posted by Carter Kozak <ck...@ckozak.net>.
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 <ga...@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
>
Re: Is a truly small core possible for 3.0?
Posted by Matt Sicker <bo...@gmail.com>.
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 <ga...@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