Re: [log4j] Overhauling API initialization in Log4j 3.x

I’ve got a much simpler refactor for API initialization which avoids introducing new SPIs (i.e., it re-uses the Provider service as-is). I’ll file it as a PR later today. It can likely be improved further (mostly related to the PropertyEnvironment init and injection), but it’s an improvement at

Re: [log4j] Overhauling API initialization in Log4j 3.x

PR created: https://github.com/apache/logging-log4j2/pull/1136 Would appreciate reviews over the next couple days. — Matt Sicker > On Nov 7, 2022, at 12:29, Matt Sicker wrote: > > I’ve got a much simpler refactor for API initialization which avoids > introducing new SPIs (i.e., it re-uses the

Re: Switch Log4j to GitHub Issues

Great questions Ralph! Let me address them: > Can we continue to use changes.xml? I propose switching to a custom changelog configuration. See LOG4J2-3628 that I have just created. > How are we going to handle issues already in Jira? I say let

Review Request: LOG4J2-3628 Migrate from maven-changes-plugin to a merge-conflict-free Markdown-based solution

In the context of migrating away from JIRA to GitHub Issues, I want to replace the current maven-changes-plugin setup with a merge-conflict-free Markdown-based solution. I have elaborated the details in LOG4J2-3628 . Since this will change the beh

Re: Review Request: LOG4J2-3628 Migrate from maven-changes-plugin to a merge-conflict-free Markdown-based solution

Just FYI, There is a release note discussion going on on the Maven list and someone said the following when I mentioned our plan to switch to GitHub Issues: "So you mean using ONLY gh for issues? So by doing this, you will exclude people living in countries banned from Github. Is it acceptable fr