Re: [ANNOUNCE] Apache Log4j 2.21.0 released
Thank you for RM'ing Christian! Gary On Mon, Oct 16, 2023, 4:28 PM Christian Grobmeier wrote: > Apache Log4j team is pleased to announce the 2.21.0 > release. Apache Log4j is a versatile, industrial-strength > Java logging framework composed of an API, its implementation, > and components to assist the deployment for various use cases. > For further information (support, download, etc.) see the project > website[1]. > > [1] https://logging.apache.org/log4j > > == Release Notes > > This release primarily focuses on enhancements to our OSGi and JPMS > support and contains several bug fixes. > It will be the first release built and signed by the CI using the > https://keyserver.ubuntu.com/pks/lookup?search=077E8893A6DCC33DD4A4D5B256E73BA9A0B592D0&op=index[ASF > Logging Services Release Manager GPG key], which is shared in > https://www.apache.org/dist/logging/KEYS[KEYS]. > > The Log4j 2.21.0 API, as well as the other artifacts, maintains binary > compatibility with the previous release. > > Apache Log4j 2.21.0 requires Java 8 to run. > The build requires JDK 11 and generates reproducible binaries. > > For complete information on Apache Log4j 2, including instructions on how > to submit bug reports, patches, get support, or suggestions for > improvement, see http://logging.apache.org/log4j/2.x/[the Apache Log4j 2 > website]. > > === OSGi changes > > All the published artifacts are OSGi bundles or fragments. > > This release introduces a change in the bundle symbolic names to allow > them to function as JPMS module name: all hyphens `-` present in the bundle > names of previous releases were replaced by dots `.`. > > === JPMS changes > > All the published artifacts have been migrated from automatic modules to > named JPMS modules. > All packages marked as private in the Javadoc are not exported. > > The module name of four bridges (`log4j-slf4j-impl`, `log4j-slf4j2-impl`, > `log4j-to-jul` and `log4j-to-slf4j`) have been changed to adhere to the > same convention as the OSGi bundle names. > > === Added > > * Added marker parent support to `JsonTemplateLayout` (#1381) > * Added https://facebook.github.io/zstd/[ZStandard compression] support > (#1508, #1514) > * Added a warning for incorrect syntax of highlighting styles (#1545, > #1637) > > === Changed > > * Open `FileExtension` methods to allow their usage in custom > ``RolloverStrategy``s (#1365, #1683) > * Bumped the minimum Java version required for the build to JDK 11. > Runtime requirements remain unchanged. (#1369) > * Set the default `minLevel` and `maxLevel` of `LevelRangeFilter` to `OFF` > and `ALL`, respectively (#1503) > * Removed additional `isFiltered` checks in `AsyncLoggerConfig` (#1550) > * Use Java version-specific warnings in `StackLocator` (#1760) > * Started logging a status error event instead of an NPE in > `OsgiServiceLocator.loadServices(Class, Lookup, boolean)` when a bundle has > no valid `BundleContext` for a service type > * Implemented a CI-based release process > * Update Eclipse Angus Activation to version > https://github.com/eclipse-ee4j/angus-activation/releases/tag/2.0.1[2.0.1] > (#1591) > * Update Eclipse Angus Mail to version > https://github.com/eclipse-ee4j/angus-mail/releases/tag/2.0.2[2.0.2] > (#1591) > * Update `com.datastax.cassandra:cassandra-driver-core` to version 3.11.5 > (#1591) > * Update Apache Cassandra to version > https://github.com/apache/cassandra/blob/cassandra-3.11/CHANGES.txt[3.11.16] > (#1591) > * Update Apache Commons Compress to version > https://commons.apache.org/proper/commons-compress/changes-report.html#a1.24.0[1.24.0] > (#1591) > * Update Apache Commons CSV to version > https://commons.apache.org/proper/commons-csv/changes-report.html#a1.10.0[1.10.0] > (#1591) > * Update Jackson to version > https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.15.2[2.15.2] > (#1591) > * Update Jakarta Activation API to version > https://jakarta.ee/specifications/activation/2.1/changelog/[2.1.2] (#1591) > * Update Jakarta Mail API to version > https://jakarta.ee/specifications/mail/2.1/changelog/[2.1.2] (#1591) > * Update JCTools to version > https://github.com/JCTools/JCTools/blob/master/RELEASE-NOTES.md[4.0.1] > (#1591) > * Update Apache Kafka to version > https://archive.apache.org/dist/kafka/3.4.0/RELEASE_NOTES.html[3.4.0] > (#1591) > * Update Kubernetes client to version > https://github.com/fabric8io/kubernetes-client/releases?q=5.12.4[5.12.4] > (#1591) > * Update `org.mongodb:mongodb-driver-core` to version 4.10.2 (#1591) > * Update `io.netty:netty-bom` to version 4.1.97 (#1591) > * Update Spring Boot to version > https://github.com/spring-projects/spring-boot/releases/tag/v2.7.15[2.7.15] > (#1591) > * Update Spring Framework to version > https://github.com/spring-projects/spring-framework/releases/tag/v5.3.29[5.3.29] > (#1591) > * Update Tomcat JULI to version 10.0.27 (#1591) > * Update Woodstox to version > https://github.com/FasterXML/woodstox/blob/master/release-notes/VERSION[6.5.1] > (#159
Re: JDBC optimizations in 3.x
Below... On Mon, Oct 16, 2023 at 7:38 AM Piotr P. Karwasz wrote: > > Hi all, > > While checking out the module descriptors of `3.x` I have some > propositions of improvements to `log4j-jdbc` that I would like to run > by you before creating the appropriate Github issues: > > 1. The `log4j-jdbc` module depends on the optional presence of > `log4j-jndi`. Maybe we should split JNDI support into a > `log4j-jdbc-jndi` artifact. This way users that do not use JNDI can be > 100% certain that no JNDI code is present. Users that require JNDI > have a single dependency to add (`log4j-jdbc-jndi`), Fine with me but in general I like to only split out this kind of dependency to avoid optional jar dependencies in a pom.xml. I'll go with the consensus on this one. > 2. There are two ways to map event data to columns: ColumnConfig and > ColumnMapping. It is unclear to me which way is the recommended one. > Since we can perform breaking changes in 3.x, could we remove one of > these methods? I would not REMOVE one, I would merge the functionality of both into one, probably into ColumnMapping since it is at the "db" level instead of the lower "jdbc" level. Either way, merging is the way to go, at least without taking a deep dive back into it. I can tell you that I rely on the JDBC and DBCP variant module. > 3. Literal values are inserted AS-IS into the prepared statement. Java > 9 introduced `Statement#enquoteLiteral`, maybe we should use it by > default, so users are not required to quote the value themselves. We > can provide an additional `quoteLiteral` attribute with a default of > true, to allow users to add whatever they want to the prepared > statement unquoted, I can't say without trying the API and seeing how it works in practice. I would do 3 above first to avoid duplicating work. > 4. The appender itself is quite wasteful in the number of connections > it uses (one per log message). IIRC JDBC connections are not > thread-safe, but can be used from multiple threads if synchronization > is provided. `AbstractDatabaseManager#write` provides such a > synchronization. With the current connection usage pattern, the > "DriverManager" connection source is basically useless. > 5. We should consider integrating the JDBC pooling features with PR > 1401: https://github.com/apache/logging-log4j2/pull/1401. Pooling is already supported by the jdbc-dbcp2 module. What am I missing? Gary > > Piotr
[ANNOUNCE] Apache Log4j 2.21.0 released
Apache Log4j team is pleased to announce the 2.21.0 release. Apache Log4j is a versatile, industrial-strength Java logging framework composed of an API, its implementation, and components to assist the deployment for various use cases. For further information (support, download, etc.) see the project website[1]. [1] https://logging.apache.org/log4j == Release Notes This release primarily focuses on enhancements to our OSGi and JPMS support and contains several bug fixes. It will be the first release built and signed by the CI using the https://keyserver.ubuntu.com/pks/lookup?search=077E8893A6DCC33DD4A4D5B256E73BA9A0B592D0&op=index[ASF Logging Services Release Manager GPG key], which is shared in https://www.apache.org/dist/logging/KEYS[KEYS]. The Log4j 2.21.0 API, as well as the other artifacts, maintains binary compatibility with the previous release. Apache Log4j 2.21.0 requires Java 8 to run. The build requires JDK 11 and generates reproducible binaries. For complete information on Apache Log4j 2, including instructions on how to submit bug reports, patches, get support, or suggestions for improvement, see http://logging.apache.org/log4j/2.x/[the Apache Log4j 2 website]. === OSGi changes All the published artifacts are OSGi bundles or fragments. This release introduces a change in the bundle symbolic names to allow them to function as JPMS module name: all hyphens `-` present in the bundle names of previous releases were replaced by dots `.`. === JPMS changes All the published artifacts have been migrated from automatic modules to named JPMS modules. All packages marked as private in the Javadoc are not exported. The module name of four bridges (`log4j-slf4j-impl`, `log4j-slf4j2-impl`, `log4j-to-jul` and `log4j-to-slf4j`) have been changed to adhere to the same convention as the OSGi bundle names. === Added * Added marker parent support to `JsonTemplateLayout` (#1381) * Added https://facebook.github.io/zstd/[ZStandard compression] support (#1508, #1514) * Added a warning for incorrect syntax of highlighting styles (#1545, #1637) === Changed * Open `FileExtension` methods to allow their usage in custom ``RolloverStrategy``s (#1365, #1683) * Bumped the minimum Java version required for the build to JDK 11. Runtime requirements remain unchanged. (#1369) * Set the default `minLevel` and `maxLevel` of `LevelRangeFilter` to `OFF` and `ALL`, respectively (#1503) * Removed additional `isFiltered` checks in `AsyncLoggerConfig` (#1550) * Use Java version-specific warnings in `StackLocator` (#1760) * Started logging a status error event instead of an NPE in `OsgiServiceLocator.loadServices(Class, Lookup, boolean)` when a bundle has no valid `BundleContext` for a service type * Implemented a CI-based release process * Update Eclipse Angus Activation to version https://github.com/eclipse-ee4j/angus-activation/releases/tag/2.0.1[2.0.1] (#1591) * Update Eclipse Angus Mail to version https://github.com/eclipse-ee4j/angus-mail/releases/tag/2.0.2[2.0.2] (#1591) * Update `com.datastax.cassandra:cassandra-driver-core` to version 3.11.5 (#1591) * Update Apache Cassandra to version https://github.com/apache/cassandra/blob/cassandra-3.11/CHANGES.txt[3.11.16] (#1591) * Update Apache Commons Compress to version https://commons.apache.org/proper/commons-compress/changes-report.html#a1.24.0[1.24.0] (#1591) * Update Apache Commons CSV to version https://commons.apache.org/proper/commons-csv/changes-report.html#a1.10.0[1.10.0] (#1591) * Update Jackson to version https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.15.2[2.15.2] (#1591) * Update Jakarta Activation API to version https://jakarta.ee/specifications/activation/2.1/changelog/[2.1.2] (#1591) * Update Jakarta Mail API to version https://jakarta.ee/specifications/mail/2.1/changelog/[2.1.2] (#1591) * Update JCTools to version https://github.com/JCTools/JCTools/blob/master/RELEASE-NOTES.md[4.0.1] (#1591) * Update Apache Kafka to version https://archive.apache.org/dist/kafka/3.4.0/RELEASE_NOTES.html[3.4.0] (#1591) * Update Kubernetes client to version https://github.com/fabric8io/kubernetes-client/releases?q=5.12.4[5.12.4] (#1591) * Update `org.mongodb:mongodb-driver-core` to version 4.10.2 (#1591) * Update `io.netty:netty-bom` to version 4.1.97 (#1591) * Update Spring Boot to version https://github.com/spring-projects/spring-boot/releases/tag/v2.7.15[2.7.15] (#1591) * Update Spring Framework to version https://github.com/spring-projects/spring-framework/releases/tag/v5.3.29[5.3.29] (#1591) * Update Tomcat JULI to version 10.0.27 (#1591) * Update Woodstox to version https://github.com/FasterXML/woodstox/blob/master/release-notes/VERSION[6.5.1] (#1591) === Removed * Moved `log4j-jmx-gui` to https://github.com/apache/logging-log4j-jmx-gui/actions[its own repository] along with its own release cycle === Fixed * Added validation to rolling file manager path conditions (#1231) * Adapted the OSGi metadata of `log4j-
Re: Failing tests (was: [VOTE] Release Apache Log4j 2.21.0)
Hi Matt, On Mon, 16 Oct 2023 at 19:10, Matt Sicker wrote: > > I’ve seen that test fail in CI before as well. I wonder if there’s any > firewall issues that can interfere with it, or if it relies on some > potentially unusable state like a common port number. I switched to ephemeral ports recently, but I might have introduced some race condition. Besides, it's UDP, so a non-reliable transport. Piotr
Re: [VOTE] Release Apache Log4j 2.21.0
Here is my own +1 With that, this vote passes with 5x +1 from: Volkan Yazici Piotr Karawasz Gary Gregory Ralph Goers Christian Grobmeier I will proceed with the following steps soon Thanks to everybody who voted! Christian On Fri, Oct 13, 2023, at 11:08, Christian Grobmeier wrote: > This is a vote to release the Apache Log4j 2.21.0. > > Website: https://logging-log4j.staged.apache.org/log4j/2.x/ > GitHub: https://github.com/apache/logging-log4j2 > Commit: 493d9a9daabc72d10582c4682538baa93a2a > Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j > Nexus: > https://repository.apache.org/content/repositories/orgapachelogging-1202 > Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0 > > Please download, test, and cast your votes on this mailing list. > > [ ] +1, release the artifacts > [ ] -1, don't release, because... > > This vote is open for 72 hours and will pass unless getting a > net negative vote count. All votes are welcome and we encourage > everyone to test the release, but only the Logging Services PMC > votes are officially counted. > > == Release Notes > > This release primarily focuses on enhancements to our OSGi and JPMS > support and contains several bug fixes. > It will be the first release built and signed by the CI using the > https://keyserver.ubuntu.com/pks/lookup?search=077E8893A6DCC33DD4A4D5B256E73BA9A0B592D0&op=index[ASF > > Logging Services Release Manager GPG key], which is shared in > https://www.apache.org/dist/logging/KEYS[KEYS]. > > The Log4j 2.21.0 API, as well as the other artifacts, maintains binary > compatibility with the previous release. > > Apache Log4j 2.21.0 requires Java 8 to run. > The build requires JDK 11 and generates reproducible binaries. > > For complete information on Apache Log4j 2, including instructions on > how to submit bug reports, patches, get support, or suggestions for > improvement, see http://logging.apache.org/log4j/2.x/[the Apache Log4j > 2 website]. > > === OSGi changes > > All the published artifacts are OSGi bundles or fragments. > > This release introduces a change in the bundle symbolic names to allow > them to function as JPMS module name: all hyphens `-` present in the > bundle names of previous releases were replaced by dots `.`. > > === JPMS changes > > All the published artifacts have been migrated from automatic modules > to named JPMS modules. > All packages marked as private in the Javadoc are not exported. > > The module name of four bridges (`log4j-slf4j-impl`, > `log4j-slf4j2-impl`, `log4j-to-jul` and `log4j-to-slf4j`) have been > changed to adhere to the same convention as the OSGi bundle names. > > > === Added > > * Added marker parent support to `JsonTemplateLayout` (#1381) > * Added https://facebook.github.io/zstd/[ZStandard compression] support > (#1508, #1514) > * Added a warning for incorrect syntax of highlighting styles (#1545, > #1637) > > === Changed > > * Open `FileExtension` methods to allow their usage in custom > ``RolloverStrategy``s (#1365, #1683) > * Bumped the minimum Java version required for the build to JDK 11. > Runtime requirements remain unchanged. (#1369) > * Set the default `minLevel` and `maxLevel` of `LevelRangeFilter` to > `OFF` and `ALL`, respectively (#1503) > * Removed additional `isFiltered` checks in `AsyncLoggerConfig` (#1550) > * Use Java version-specific warnings in `StackLocator` (#1760) > * Started logging a status error event instead of an NPE in > `OsgiServiceLocator.loadServices(Class, Lookup, boolean)` when a bundle > has no valid `BundleContext` for a service type > * Implemented a CI-based release process > * Update Eclipse Angus Activation to version > https://github.com/eclipse-ee4j/angus-activation/releases/tag/2.0.1[2.0.1] > (#1591) > * Update Eclipse Angus Mail to version > https://github.com/eclipse-ee4j/angus-mail/releases/tag/2.0.2[2.0.2] > (#1591) > * Update `com.datastax.cassandra:cassandra-driver-core` to version > 3.11.5 (#1591) > * Update Apache Cassandra to version > https://github.com/apache/cassandra/blob/cassandra-3.11/CHANGES.txt[3.11.16] > (#1591) > * Update Apache Commons Compress to version > https://commons.apache.org/proper/commons-compress/changes-report.html#a1.24.0[1.24.0] > > (#1591) > * Update Apache Commons CSV to version > https://commons.apache.org/proper/commons-csv/changes-report.html#a1.10.0[1.10.0] > > (#1591) > * Update Jackson to version > https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.15.2[2.15.2] > (#1591) > * Update Jakarta Activation API to version > https://jakarta.ee/specifications/activation/2.1/changelog/[2.1.2] > (#1591) > * Update Jakarta Mail API to version > https://jakarta.ee/specifications/mail/2.1/changelog/[2.1.2] (#1591) > * Update JCTools to version > https://github.com/JCTools/JCTools/blob/master/RELEASE-NOTES.md[4.0.1] > (#1591) > * Update Apache Kafka to version > https://archive.apache.org/dist/kafka/3.4.0/RELEASE_NOTES.html[3.4.0] > (#1591) > *
Re: Failing tests (was: [VOTE] Release Apache Log4j 2.21.0)
I’ve seen that test fail in CI before as well. I wonder if there’s any firewall issues that can interfere with it, or if it relies on some potentially unusable state like a common port number. > On Oct 16, 2023, at 8:06 AM, Ralph Goers wrote: > > I enabled that profile. Log4j-core-test failed after just over 23 minutes. > > [INFO] > [INFO] Results: > [INFO] > [ERROR] Failures: > [ERROR] > TlsSyslogAppenderTest>SyslogAppenderTest.testUDPAppender:80->SyslogAppenderTestBase.sendAndCheckLegacyBsdMessage:75->SyslogAppenderTestBase.checkTheNumberOfSentAndReceivedMessages:113 > The number of received messages should be equal with the number of sent > messages expected:<1> but was:<0> > [INFO] > [ERROR] Tests run: 2782, Failures: 1, Errors: 0, Skipped: 38 > > Ralph > >> On Oct 15, 2023, at 12:32 PM, Piotr P. Karwasz >> wrote: >> >> Hi Ralph, >> >> On Sun, 15 Oct 2023 at 00:49, Ralph Goers wrote: >>> My first attempt at building from the source failed with >>> >>> [ERROR] >>> SyslogAppenderCustomLayoutTest>SyslogAppenderTest.testUDPAppender:80->SyslogAppenderTestBase.sendAndCheckLegacyBsdMessage:75->SyslogAppenderTestBase.checkTheNumberOfSentAndReceivedMessages:113 >>> The number of received messages should be equal with the number of sent >>> messages expected:<1> but was:<0> >>> >>> My second attempt failed with >>> >>> [ERROR] Failures: >>> [ERROR] SystemClockTest.testAfterWaitStillLessThan2Millis:43 diff too >>> large: 12 ==> expected: but was: >>> >>> On the third try the build succeeded. >>> >>> On the positive side, log4j-core-tests only takes a little over 4 minutes >>> now on my new MacBook Pro and the entire build completed in 13 minutes. >> >> I am afraid we will continuously need to improve the parallelisation >> of tests, but I am assuming you are not complaining? Scalability is >> never linear, but I would expect that a `-Psequential-tests` run would >> take something like 20-25 minutes on your computer? >> >> Piotr >
Re: JDBC optimizations in 3.x
> On Oct 16, 2023, at 6:38 AM, Piotr P. Karwasz wrote: > > 2. There are two ways to map event data to columns: ColumnConfig and > ColumnMapping. It is unclear to me which way is the recommended one. > Since we can perform breaking changes in 3.x, could we remove one of > these methods? I added ColumnMapping in 2.8 originally for the Cassandra appender, but that was later integrated into the other database appenders. I suggest we stick with ColumnMapping as the more flexible approach.
Re: Failing tests (was: [VOTE] Release Apache Log4j 2.21.0)
I enabled that profile. Log4j-core-test failed after just over 23 minutes. [INFO] [INFO] Results: [INFO] [ERROR] Failures: [ERROR] TlsSyslogAppenderTest>SyslogAppenderTest.testUDPAppender:80->SyslogAppenderTestBase.sendAndCheckLegacyBsdMessage:75->SyslogAppenderTestBase.checkTheNumberOfSentAndReceivedMessages:113 The number of received messages should be equal with the number of sent messages expected:<1> but was:<0> [INFO] [ERROR] Tests run: 2782, Failures: 1, Errors: 0, Skipped: 38 Ralph > On Oct 15, 2023, at 12:32 PM, Piotr P. Karwasz > wrote: > > Hi Ralph, > > On Sun, 15 Oct 2023 at 00:49, Ralph Goers wrote: >> My first attempt at building from the source failed with >> >> [ERROR] >> SyslogAppenderCustomLayoutTest>SyslogAppenderTest.testUDPAppender:80->SyslogAppenderTestBase.sendAndCheckLegacyBsdMessage:75->SyslogAppenderTestBase.checkTheNumberOfSentAndReceivedMessages:113 >> The number of received messages should be equal with the number of sent >> messages expected:<1> but was:<0> >> >> My second attempt failed with >> >> [ERROR] Failures: >> [ERROR] SystemClockTest.testAfterWaitStillLessThan2Millis:43 diff too >> large: 12 ==> expected: but was: >> >> On the third try the build succeeded. >> >> On the positive side, log4j-core-tests only takes a little over 4 minutes >> now on my new MacBook Pro and the entire build completed in 13 minutes. > > I am afraid we will continuously need to improve the parallelisation > of tests, but I am assuming you are not complaining? Scalability is > never linear, but I would expect that a `-Psequential-tests` run would > take something like 20-25 minutes on your computer? > > Piotr
Re: JDBC optimizations in 3.x
Great questions and I will address each one, hopefully later today. Gary On Mon, Oct 16, 2023, 7:38 AM Piotr P. Karwasz wrote: > Hi all, > > While checking out the module descriptors of `3.x` I have some > propositions of improvements to `log4j-jdbc` that I would like to run > by you before creating the appropriate Github issues: > > 1. The `log4j-jdbc` module depends on the optional presence of > `log4j-jndi`. Maybe we should split JNDI support into a > `log4j-jdbc-jndi` artifact. This way users that do not use JNDI can be > 100% certain that no JNDI code is present. Users that require JNDI > have a single dependency to add (`log4j-jdbc-jndi`), > 2. There are two ways to map event data to columns: ColumnConfig and > ColumnMapping. It is unclear to me which way is the recommended one. > Since we can perform breaking changes in 3.x, could we remove one of > these methods? > 3. Literal values are inserted AS-IS into the prepared statement. Java > 9 introduced `Statement#enquoteLiteral`, maybe we should use it by > default, so users are not required to quote the value themselves. We > can provide an additional `quoteLiteral` attribute with a default of > true, to allow users to add whatever they want to the prepared > statement unquoted, > 4. The appender itself is quite wasteful in the number of connections > it uses (one per log message). IIRC JDBC connections are not > thread-safe, but can be used from multiple threads if synchronization > is provided. `AbstractDatabaseManager#write` provides such a > synchronization. With the current connection usage pattern, the > "DriverManager" connection source is basically useless. > 5. We should consider integrating the JDBC pooling features with PR > 1401: https://github.com/apache/logging-log4j2/pull/1401. > > Piotr >
JDBC optimizations in 3.x
Hi all, While checking out the module descriptors of `3.x` I have some propositions of improvements to `log4j-jdbc` that I would like to run by you before creating the appropriate Github issues: 1. The `log4j-jdbc` module depends on the optional presence of `log4j-jndi`. Maybe we should split JNDI support into a `log4j-jdbc-jndi` artifact. This way users that do not use JNDI can be 100% certain that no JNDI code is present. Users that require JNDI have a single dependency to add (`log4j-jdbc-jndi`), 2. There are two ways to map event data to columns: ColumnConfig and ColumnMapping. It is unclear to me which way is the recommended one. Since we can perform breaking changes in 3.x, could we remove one of these methods? 3. Literal values are inserted AS-IS into the prepared statement. Java 9 introduced `Statement#enquoteLiteral`, maybe we should use it by default, so users are not required to quote the value themselves. We can provide an additional `quoteLiteral` attribute with a default of true, to allow users to add whatever they want to the prepared statement unquoted, 4. The appender itself is quite wasteful in the number of connections it uses (one per log message). IIRC JDBC connections are not thread-safe, but can be used from multiple threads if synchronization is provided. `AbstractDatabaseManager#write` provides such a synchronization. With the current connection usage pattern, the "DriverManager" connection source is basically useless. 5. We should consider integrating the JDBC pooling features with PR 1401: https://github.com/apache/logging-log4j2/pull/1401. Piotr
