Is a truly small core possible for 3.0?

[Gary Gregory]

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?

[Ralph Goers]

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  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: [apache/logging-log4j2] Bump tomcat-catalina from 8.5.20 to 10.0.14 (PR #662)

[Volkan Yazıcı]

Mind somebody reviewing the following PR, please?
https://github.com/apache/logging-log4j2/pull/730
Time, what do you think?

On Mon, Jan 24, 2022 at 10:21 PM Tim Perry  wrote:

> Sorry Volkan, I think I somehow searched the wrong pom.xml. I was convinced
> appserver was bringing in log4j-jms, but it isn't.
>
> You will need to update the servlet version. This won't work with Tomcat
> 10:
> 
> javax.servlet
> javax.servlet-api
> 3.0.1
> provided
> 
>
> Sorry for the confusion.
>
> On Mon, Jan 24, 2022 at 1:09 PM Volkan Yazıcı  wrote:
>
> > This PR only addresses `log4j-appserver`, which doesn't have any `javax`
> > package dependencies. Quoting from my comment to the PR:
> >
> > "AFAIK, Tomcat is only used by `log4j-appserver`. There I don't see any
> > dependencies on the `javax` namespace, but just an implementation of
> > `org.apache.juli.logging.Log` packaged by Tomcat. All CI checks also look
> > green – note that there are no tests associated with `log4j-appserver`,
> > though compilation succeeds. I don't see a reason not to upgrade. If the
> > user wants to stick to a Tomcat version <10, they can still do so.
> > `org.apache.juli.logging.Log` looks to be intact, hence I don't foresee
> any
> > compatibility issues."
> >
> > Hence I still think this is a legit upgrade. Am I missing something?
> >
> > On Sun, Jan 23, 2022 at 1:14 AM Tim Perry  wrote:
> >
> > > Many libraries are producing one code line for the javax.* environment
> > and
> > > another code line for the jakarta.* environment. This is because when
> > > Oracle gave the Eclipse Foundation the J2EE code they required name
> > > changes. This affects code using Servlet API, JPA, Bean Validation,et
> > > cetera.
> > >
> > > Spring:
> > > spring 5 uses javax.* and spring 6 will support jakarta.*
> > >
> > > Hibernate:
> > > Hibernate Validator 6.x will keep the javax.* packages while Hibernate
> > > Validator 7.x moved to the jakarta.* packages.
> > >
> > >
> >
> https://in.relation.to/2021/01/06/hibernate-validator-700-62-final-released/
> > >
> > > Tomcat:
> > > When first released, Tomcat 9 and Tomcat 10 were functionally
> identical,
> > > except Tomcat 10 supported jakarta.* and Tomcat 9 supported javax.*.
> They
> > > have slowly diverged as more features have been added to Tomcat 10. The
> > > difference isn't very big.
> > >
> > >
> > > For log4j, I suspect we'll need to release two versions of log4j-web
> and
> > > log4j-jpa: one for backwards compatibility with javax.* and another for
> > > Jakarta EE. We might need to do this for other libs as well.
> > >
> > > Looking through the source, I only see "import javax.servlet" in:
> > > log4j-samples
> > > log4j-taglib
> > > log4j-web
> > > src/site/asciidoc
> > >
> > > I see "import javax.persistence in:
> > > log4j-jpa
> > > log4j-perf
> > >
> > > If I expand my search to "import javax", I see this many more places. I
> > > don't think all of these are affected by the Jakarta EE change. If I
> was
> > at
> > > a unix box I could slice and dice the imports, but here are the
> packages
> > > that might be affected.
> > > log4j-1.2-api
> > > log4j-core
> > > log4j-flume-ng
> > > log4j-jdbc
> > > log4j-jms
> > > log4j-jmx-guil
> > > log4j-jpa
> > > log4j-kafka
> > > log4j-layout-jakcons-xml
> > > log4j-perf
> > > log4j-plugins
> > > log4j-samples
> > > log4j-smtp
> > > log4j-taglib
> > > log4j-web
> > > src/site/asciidoc
> > >
> > > FWIW, I think I tabulated these on an old master branch.
> > >
> > > On Fri, Jan 21, 2022 at 12:26 AM Volkan Yazıcı  wrote:
> > >
> > > > This Tomcat upgrade looks legit to me.
> > > > Nevertheless, I'd appreciate it if a Tomcat veteran could weigh in.
> > > >
> > > > -- Forwarded message -
> > > > From: knoxyz 
> > > > Date: Thu, Jan 20, 2022 at 3:28 PM
> > > > Subject: Re: [apache/logging-log4j2] Bump tomcat-catalina from 8.5.20
> > to
> > > > 10.0.14 (PR #662)
> > > > To: apache/logging-log4j2 
> > > > Cc: Subscribed 
> > > >
> > > >
> > > > Pay attention!
> > > > tomcat 8 and 9 are pretty good compatible, but with version 10 comes
> > huge
> > > > breaks (namespace javax -> jakarta)!
> > > > Therefore still tomcat 9 is in use by the most production
> environments
> > > and
> > > > not supported from the most API and frameworks.
> > > >
> > > > https://tomcat.apache.org/migration-10.html
> > > >
> > > > *There is a significant breaking change between Tomcat 9.0.x and
> Tomcat
> > > > 10.0.x. The Java package used by the specification APIs has changed
> > from
> > > > javax... to jakarta It will be necessary to recompile web
> > > applications
> > > > against the new APIs.*
> > > >
> > > > tomcat 8 and 9
> > > >
> > > > —
> > > > Reply to this email directly, view it on GitHub
> > > > <
> > >
> >
> https://github.com/apache/logging-log4j2/pull/662#issuecomment-1017564083
> > > > >,
> > > > or unsubscribe
> > > > <
> > > >
> > >
> >
> https://github.com/notifications/unsubscribe-auth/AAARTSPJ3TLBKEMT2FHBXW3UXALXHANCNFSM5KZH66WA
> > > > >

LOG4J2-3260 Missing branch protection settings

[Volkan Yazıcı]

According to the OSSF Scorecards , we
are missing two check marks (LOG4J2-3260
) there:

   1. Require code review (every change goes into a PR and requires at
   least one reviewer)
   2. Require a CI status check

Even though I admit with the convenience of freedom we have right now, I
personally find it difficult to keep track of what is going in and out.
This convention does not aim to obstruct the development progress, but
rather improve the overall code quality and spread the know-how in a
scalable way. Hence, I want to implement this feature on `release-2.x` and
`master` branches. Thoughts?

Re: LOG4J2-3260 Missing branch protection settings

[Carter Kozak]

I'd love to start using the github PR workflow for our contributions. I've been 
using them for my changes for a while and find it much easier than running a 
full build locally to verify each change on my development system.
While we've historically used "commit then review", I find it much easier to 
consolidate review and discussion on pull requests, which results in cleaner 
history, and clearer historical context in one place when changes are 
requested. The downside is that it means merging changes is blocked on other 
committers, so we must be cognizant of that when PRs are opened, keeping a 
balance of timely reviews and patience.

While this isn't an issue for our own changes, we may need to figure something 
out to improve the experience of adding changelog entries for third-party 
contributions, however those are a minority and I wouldn't block on solving 
that problem.

Carter

On Wed, Jan 26, 2022, at 15:25, Volkan Yazıcı wrote:
> According to the OSSF Scorecards , we
> are missing two check marks (LOG4J2-3260
> ) there:
> 
>1. Require code review (every change goes into a PR and requires at
>least one reviewer)
>2. Require a CI status check
> 
> Even though I admit with the convenience of freedom we have right now, I
> personally find it difficult to keep track of what is going in and out.
> This convention does not aim to obstruct the development progress, but
> rather improve the overall code quality and spread the know-how in a
> scalable way. Hence, I want to implement this feature on `release-2.x` and
> `master` branches. Thoughts?
> 

Re: LOG4J2-3260 Missing branch protection settings

[Matt Sicker]

I'd be on board with this. It might be worth having some rule that if
a committer's PR goes unreviewed for over a certain period of time,
then the committer can just merge the PR after it passes the automated
checks. I don't want this project's development to end up stalled
because everyone is either too busy or too inexperienced to review PRs
from each other, but I'd love for us to use a better UI for doing
these reviews in the first place.

On a related note, it'd be great if PRs and commits didn't generate
like 3+ duplicate emails each.

On Wed, Jan 26, 2022 at 3:40 PM Carter Kozak  wrote:
>
> I'd love to start using the github PR workflow for our contributions. I've 
> been using them for my changes for a while and find it much easier than 
> running a full build locally to verify each change on my development system.
> While we've historically used "commit then review", I find it much easier to 
> consolidate review and discussion on pull requests, which results in cleaner 
> history, and clearer historical context in one place when changes are 
> requested. The downside is that it means merging changes is blocked on other 
> committers, so we must be cognizant of that when PRs are opened, keeping a 
> balance of timely reviews and patience.
>
> While this isn't an issue for our own changes, we may need to figure 
> something out to improve the experience of adding changelog entries for 
> third-party contributions, however those are a minority and I wouldn't block 
> on solving that problem.
>
> Carter
>
> On Wed, Jan 26, 2022, at 15:25, Volkan Yazıcı wrote:
> > According to the OSSF Scorecards , we
> > are missing two check marks (LOG4J2-3260
> > ) there:
> >
> >1. Require code review (every change goes into a PR and requires at
> >least one reviewer)
> >2. Require a CI status check
> >
> > Even though I admit with the convenience of freedom we have right now, I
> > personally find it difficult to keep track of what is going in and out.
> > This convention does not aim to obstruct the development progress, but
> > rather improve the overall code quality and spread the know-how in a
> > scalable way. Hence, I want to implement this feature on `release-2.x` and
> > `master` branches. Thoughts?
> >
>

Re: Is a truly small core possible for 3.0?

[Matt Sicker]

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

[Carter Kozak]

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  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: LOG4J2-3260 Missing branch protection settings

[Gary Gregory]

Not for me, this changes CTR to RTC, which is fine for work$, but too slow
for me here. When I find time for FOSS, I just want to go and do it, not
get bogged down in process. RTC is fine for a new medium to large feature,
but not for everything. Right now, I do something in release-2.x, then
cherry-pick to master, already a PITA because of the JPMS mess, now it has
to be a 4 step process instead of 2? Pass.

Gary


On Wed, Jan 26, 2022, 15:25 Volkan Yazıcı  wrote:

> According to the OSSF Scorecards , we
> are missing two check marks (LOG4J2-3260
> ) there:
>
>1. Require code review (every change goes into a PR and requires at
>least one reviewer)
>2. Require a CI status check
>
> Even though I admit with the convenience of freedom we have right now, I
> personally find it difficult to keep track of what is going in and out.
> This convention does not aim to obstruct the development progress, but
> rather improve the overall code quality and spread the know-how in a
> scalable way. Hence, I want to implement this feature on `release-2.x` and
> `master` branches. Thoughts?
>

Re: Is a truly small core possible for 3.0?

[Matt Sicker]

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

[Carter Kozak]

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  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  
> >>> 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: LOG4J2-3260 Missing branch protection settings

[Carter Kozak]

What if RTC only applied to the primary branch, release-2.x? We've had changes 
like this[1] which I discovered after the fact and wish we'd had a chance to 
discuss before it merged. Pushing changes prior to review is faster and easier 
for the committer, but ultimately creates an arduous process for reviewers. 
I've found it harder to have retroactive
conversations about changes that have already merged.

-ck

1. https://lists.apache.org/thread/qn9b22fqv4yzg6jb114ovso40fnc1k0n

On Wed, Jan 26, 2022, at 16:22, Gary Gregory wrote:
> Not for me, this changes CTR to RTC, which is fine for work$, but too slow
> for me here. When I find time for FOSS, I just want to go and do it, not
> get bogged down in process. RTC is fine for a new medium to large feature,
> but not for everything. Right now, I do something in release-2.x, then
> cherry-pick to master, already a PITA because of the JPMS mess, now it has
> to be a 4 step process instead of 2? Pass.
> 
> Gary
> 
> 
> On Wed, Jan 26, 2022, 15:25 Volkan Yazıcı  wrote:
> 
> > According to the OSSF Scorecards , we
> > are missing two check marks (LOG4J2-3260
> > ) there:
> >
> >1. Require code review (every change goes into a PR and requires at
> >least one reviewer)
> >2. Require a CI status check
> >
> > Even though I admit with the convenience of freedom we have right now, I
> > personally find it difficult to keep track of what is going in and out.
> > This convention does not aim to obstruct the development progress, but
> > rather improve the overall code quality and spread the know-how in a
> > scalable way. Hence, I want to implement this feature on `release-2.x` and
> > `master` branches. Thoughts?
> >
> 

Re: Is a truly small core possible for 3.0?

[Matt Sicker]

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

[Matt Sicker]

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