[PR] Bump com.github.spotbugs:spotbugs-annotations from 4.7.3 to 4.8.0 [logging-log4j-jmx-gui]
dependabot[bot] opened a new pull request, #1: URL: https://github.com/apache/logging-log4j-jmx-gui/pull/1 Bumps [com.github.spotbugs:spotbugs-annotations](https://github.com/spotbugs/spotbugs) from 4.7.3 to 4.8.0. Release notes Sourced from https://github.com/spotbugs/spotbugs/releases";>com.github.spotbugs:spotbugs-annotations's releases. SpotBugs 4.8.0 CHANGELOG https://github.com/spotbugs/spotbugs/blob/4.8.0/CHANGELOG.md";>https://github.com/spotbugs/spotbugs/blob/4.8.0/CHANGELOG.md CHECKSUM file checksum (sha256) spotbugs-4.8.0-javadoc.jar 4cf102aa474ce8f3728e7513c51c0710024e4cd9d6b7c07672b5e3ec0e70a848 spotbugs-4.8.0-sources.jar d1e47bd320cae314a5c2b44e52152d8ca5f5f700713ba0f497dbed0a916540c2 spotbugs-4.8.0.tgz 15a97043faef7a371ae43137805ca83e89005c22253806b7c63a60a585e794c7 spotbugs-4.8.0.zip 768ac3bd6f5c49d1f12924ff3094ff281debc0ee218ae85ce5aae6f66ca0666a spotbugs-annotations-4.8.0-javadoc.jar d8ab5ebdaccff345d7167d2518fd74db72cf6b02b259d4f011689d48351c2b3e spotbugs-annotations-4.8.0-sources.jar b5d0110b70b9c44915f2c3375d1b700acb6d409152baf70030787d17a684469b spotbugs-annotations.jar f6644de2f0dfe4b614d3c9a35e9a8f1e1da1074892c8cad7a00bb08ce7bf4eff spotbugs-ant-4.8.0-javadoc.jar 1285df769e00a9fbeb6edceec856b361fb7f5f79762d3f2a768ce71d31cf7bb5 spotbugs-ant-4.8.0-sources.jar 9f1431331363f45ceb9b91c0e5246eab574fbff81c56eff0e385f572d346de61 spotbugs-ant.jar a798346790437cdc18217379fa54a7e6b044ba2070891ebe01faee28af79af6c spotbugs.jar 1ce2fa740d7f07b802881babb27dd26f74861ff2ac938718779ce8a7cb5fe14c test-harness-4.8.0-javadoc.jar 3191c34729c1dedb4964dfc8a0cd5917457e6271291688ff6d5fc3b9c96868f6 test-harness-4.8.0-sources.jar 633ae795c1889fa59f1faad8ea8f1f5b39155029f4f75b51557085097570feb6 test-harness-4.8.0.jar 23f414f9988a3d44dded88ad2d827e95699dc6bb8d6e06a2b0920db2cac442b9 test-harness-core-4.8.0-javadoc.jar 33c6e66ac7a08344afe48aa5ba1d5be22ec79065e50b235530c02d46818a7018 test-harness-core-4.8.0-sources.jar f5db3e4ebf3f90c9bbf4815824c9d94f93fb740c9610b6f70a64bf7896a4e082 test-harness-core-4.8.0.jar 5bd0e9b18f0ec45c27ee3ec882cb6db86ed42a6b884f091468496de3281dc242 test-harness-jupiter-4.8.0-javadoc.jar 5ff08084863aa6f6579e97e83d9c0ba2b7620663d0f0b0a777f09d99ba06dc8c test-harness-jupiter-4.8.0-sources.jar 0aefbc5c8bd406e5dc0b1d59bc3afc6889c02010d486b22242f4f19a1a935800 test-harness-jupiter-4.8.0.jar d2ed802cc81dca3cf8c393fda7f77f02b01c0c1a8ffce7ec57da53aff27a1485 Changelog Sourced from https://github.com/spotbugs/spotbugs/blob/master/CHANGELOG.md";>com.github.spotbugs:spotbugs-annotations's changelog. 4.8.0 - 2023-10-11 Changed Bump up Apache Commons BCEL to the version 6.6.1 (https://redirect.github.com/spotbugs/spotbugs/pull/2223";>#2223) Bump up slf4j-api to 2.0.3 (https://redirect.github.com/spotbugs/spotbugs/pull/2220";>#2220) Bump up gson to 2.10 (https://redirect.github.com/spotbugs/spotbugs/pull/2235";>#2235) Allowed for large command line through writing arguments to file (UnionResults/UnionBugs2) Use com.github.stephenc.jcip for jcip-annotations fixing https://redirect.github.com/spotbugs/spotbugs/issues/887";>#887 Fixed Fixed missing classes not in report if using IErrorLogger.reportMissingClass(ClassDescriptor) (https://redirect.github.com/spotbugs/spotbugs/issues/219";>#219) Stop exposing junit-bom to consumers (https://redirect.github.com/spotbugs/spotbugs/pull/2255";>#2255) Fixed AbstractBugReporter emits wrong non-sensical debug output during filtering (https://redirect.github.com/spotbugs/spotbugs/issues/184";>#184) Added support for jakarta namespace (https://redirect.github.com/spotbugs/spotbugs/pull/2289";>#2289) Report a low priority bug for an unread field in reflective classes (https://redirect.github.com/spotbugs/spotbugs/issues/2325";>#2325) Fixed "Unhandled event loop exception" opening Bug Filter Configuration dialog in Eclipse (https://redirect.github.com/spotbugs/spotbugs/issues/2327";>#2327) Fixed detector RandomOnceSubDetector to not report when doubles, ints, or longs are called on a new Random or SecureRandom (https://redirect.github.com/spotbugs/spotbugs/issues/2325";>#2370) Fixed detector TestASM throwing error during analysis, because it doesn't note that it reports bugs. Eclipse annotation classpath initializer is hard-coded to jsr305 version 3.0.1, fix to 3.0.2 per https://redirect.github.com/spotbugs/spotbugs/issues/2470";>#2470 Fixed annotation on generic or array incorrectly considered for the nullability of a method parameter or return type (https://redirect.github.com/spotbugs/spotbugs/issues/2502";>#2502) Added
Re: [PR] Bump com.github.spotbugs:spotbugs-annotations from 4.7.3 to 4.8.0 [logging-log4j-jmx-gui]
vy merged PR #1: URL: https://github.com/apache/logging-log4j-jmx-gui/pull/1 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [I] This package is not in the mvn repo? [logging-log4j-jmx-gui]
MoonLord-LM commented on issue #2: URL: https://github.com/apache/logging-log4j-jmx-gui/issues/2#issuecomment-1785860608 https://github.com/apache/logging-log4j-jmx-gui/assets/8104133/4729d0f3-5a70-4dae-9751-3444d33752a0";> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [I] This package is not in the mvn repo? [logging-log4j-jmx-gui]
MoonLord-LM commented on issue #2: URL: https://github.com/apache/logging-log4j-jmx-gui/issues/2#issuecomment-1785862128 https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-bom/2.21.1 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [I] This package is not in the mvn repo? [logging-log4j-jmx-gui]
ppkarwasz commented on issue #2: URL: https://github.com/apache/logging-log4j-jmx-gui/issues/2#issuecomment-1785870820 @MoonLord-LM, Thank you for the report. The problem is that `log4j-bom` contains a bad entry, so I am closing this issue and keeping apache/logging-log4j2#1926 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [I] This package is not in the mvn repo? [logging-log4j-jmx-gui]
ppkarwasz closed issue #2: This package is not in the mvn repo? URL: https://github.com/apache/logging-log4j-jmx-gui/issues/2 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Bump org.junit:junit-bom from 5.10.0 to 5.10.1 [logging-log4j-jakarta]
dependabot[bot] opened a new pull request, #1: URL: https://github.com/apache/logging-log4j-jakarta/pull/1 Bumps [org.junit:junit-bom](https://github.com/junit-team/junit5) from 5.10.0 to 5.10.1. Release notes Sourced from https://github.com/junit-team/junit5/releases";>org.junit:junit-bom's releases. JUnit 5.10.1 = Platform 1.10.1 + Jupiter 5.10.1 + Vintage 5.10.1 See http://junit.org/junit5/docs/5.10.1/release-notes/";>Release Notes. Full Changelog: https://github.com/junit-team/junit5/compare/r5.10.0...r5.10.1";>https://github.com/junit-team/junit5/compare/r5.10.0...r5.10.1 Commits https://github.com/junit-team/junit5/commit/e5f50d8720741623915979ac154b65bcbcd6a577";>e5f50d8 Release 5.10.1 https://github.com/junit-team/junit5/commit/ac86d18e9b15dbebe046e82743ac7f9534a17582";>ac86d18 Fix typo in AfterAll documentation https://github.com/junit-team/junit5/commit/388c5beaf42944961ab5b455c900d958a6e15588";>388c5be Harmonize application of method and field filters in search algorithms https://github.com/junit-team/junit5/commit/f82dd1e716f8717e012152b1d1d5cc0da10d33cd";>f82dd1e Apply field predicate before searching type hierarchy https://github.com/junit-team/junit5/commit/1d1eb8571552bbf28e578241965010de6c8ee779";>1d1eb85 Polishing https://github.com/junit-team/junit5/commit/5ce280eff69b43759a3cb0c176207abe0a41b579";>5ce280e Update picocli to 4.7.5 and enable help width computation https://github.com/junit-team/junit5/commit/fea05c3aa80de76686f326b5ce26ddf7f153ff5a";>fea05c3 Fix ConsoleLauncherTests and StandaloneTests https://github.com/junit-team/junit5/commit/c5567354c2556e772f8a0035ef7647161011d1c0";>c556735 Use same expected files for all JDK versions https://github.com/junit-team/junit5/commit/808493ab09b30970b506a48fda3d616ac1ba4fff";>808493a Run StandaloneTests for Java 8 under Java 8 https://github.com/junit-team/junit5/commit/9ec57661c78c3889db004ab6a89416e56a2fb2e0";>9ec5766 Unify messages about exit codes in StandaloneTests Additional commits viewable in https://github.com/junit-team/junit5/compare/r5.10.0...r5.10.1";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Bump jakarta.platform:jakarta.jakartaee-bom from 9.1.0 to 10.0.0 [logging-log4j-jakarta]
dependabot[bot] opened a new pull request, #2: URL: https://github.com/apache/logging-log4j-jakarta/pull/2 Bumps jakarta.platform:jakarta.jakartaee-bom from 9.1.0 to 10.0.0. [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Bump org.mockito:mockito-bom from 5.5.0 to 5.7.0 [logging-log4j-jakarta]
dependabot[bot] opened a new pull request, #3: URL: https://github.com/apache/logging-log4j-jakarta/pull/3 Bumps [org.mockito:mockito-bom](https://github.com/mockito/mockito) from 5.5.0 to 5.7.0. Release notes Sourced from https://github.com/mockito/mockito/releases";>org.mockito:mockito-bom's releases. v5.7.0 Changelog generated by https://github.com/shipkit/shipkit-changelog";>Shipkit Changelog Gradle Plugin 5.7.0 2023-11-02 - https://github.com/mockito/mockito/compare/v5.6.0...v5.7.0";>15 commit(s) by Stefan M, Tim van der Lippe, Valery Yatsynovich, Vladimir Glinskikh, ascopes, dependabot[bot] Bump org.jetbrains.kotlin:kotlin-gradle-plugin from 1.9.10 to 1.9.20 [(https://redirect.github.com/mockito/mockito/issues/3166";>#3166)](https://redirect.github.com/mockito/mockito/pull/3166";>mockito/mockito#3166) Bump org.jetbrains.kotlin:kotlin-stdlib from 1.9.10 to 1.9.20 [(https://redirect.github.com/mockito/mockito/issues/3165";>#3165)](https://redirect.github.com/mockito/mockito/pull/3165";>mockito/mockito#3165) Attempt to detect system property mangling prior to loading ByteBuddy. [(https://redirect.github.com/mockito/mockito/issues/3164";>#3164)](https://redirect.github.com/mockito/mockito/pull/3164";>mockito/mockito#3164) Handle Termux in InlineDelegateByteBuddyMockMaker.java [(https://redirect.github.com/mockito/mockito/issues/3158";>#3158)](https://redirect.github.com/mockito/mockito/pull/3158";>mockito/mockito#3158) Bump versions.errorprone from 2.22.0 to 2.23.0 [(https://redirect.github.com/mockito/mockito/issues/3153";>#3153)](https://redirect.github.com/mockito/mockito/pull/3153";>mockito/mockito#3153) Fix license url according to spdx license spec [(https://redirect.github.com/mockito/mockito/issues/3152";>#3152)](https://redirect.github.com/mockito/mockito/pull/3152";>mockito/mockito#3152) Remove checks for unsupported Java version from unit tests [(https://redirect.github.com/mockito/mockito/issues/3150";>#3150)](https://redirect.github.com/mockito/mockito/pull/3150";>mockito/mockito#3150) Add CodeCov token to upload coverage report [(https://redirect.github.com/mockito/mockito/issues/3149";>#3149)](https://redirect.github.com/mockito/mockito/pull/3149";>mockito/mockito#3149) Migrate to JaCoCo 0.8.11 [(https://redirect.github.com/mockito/mockito/issues/3147";>#3147)](https://redirect.github.com/mockito/mockito/pull/3147";>mockito/mockito#3147) Add Java 21 to CI build matrix [(https://redirect.github.com/mockito/mockito/issues/3145";>#3145)](https://redirect.github.com/mockito/mockito/pull/3145";>mockito/mockito#3145) Feat: add generic-inferred methods for constructing ArgumentCaptors [(https://redirect.github.com/mockito/mockito/issues/3144";>#3144)](https://redirect.github.com/mockito/mockito/pull/3144";>mockito/mockito#3144) Bump gradle from 8.2 to 8.4 [(https://redirect.github.com/mockito/mockito/issues/3142";>#3142)](https://redirect.github.com/mockito/mockito/pull/3142";>mockito/mockito#3142) Bump com.github.ben-manes.versions from 0.48.0 to 0.49.0 [(https://redirect.github.com/mockito/mockito/issues/3139";>#3139)](https://redirect.github.com/mockito/mockito/pull/3139";>mockito/mockito#3139) Bump versions.bytebuddy from 1.14.8 to 1.14.9 [(https://redirect.github.com/mockito/mockito/issues/3138";>#3138)](https://redirect.github.com/mockito/mockito/pull/3138";>mockito/mockito#3138) Bump biz.aQute.bnd.builder from 6.4.0 to 7.0.0 [(https://redirect.github.com/mockito/mockito/issues/3135";>#3135)](https://redirect.github.com/mockito/mockito/pull/3135";>mockito/mockito#3135) v5.6.0 Changelog generated by https://github.com/shipkit/shipkit-changelog";>Shipkit Changelog Gradle Plugin 5.6.0 2023-10-06 - https://github.com/mockito/mockito/compare/v5.5.0...v5.6.0";>22 commit(s) by Andreas Turban, Stefan M, StevenCurran, Yevhen Lazhyntsev, dependabot[bot] Use spdx identifier for license name [(https://redirect.github.com/mockito/mockito/issues/3134";>#3134)](https://redirect.github.com/mockito/mockito/pull/3134";>mockito/mockito#3134) Fixes https://redirect.github.com/mockito/mockito/issues/1382";>#1382 Jupiter Captor annotation support [(https://redirect.github.com/mockito/mockito/issues/3133";>#3133)](https://redirect.github.com/mockito/mockito/pull/3133";>mockito/mockito#3133) Bump com.gradle.enterprise from 3.15 to 3.15.1 [(https://redirect.github.com/mockito/mockito/issues/3132";>#3132)](https://redirect.github.com/mockito/mockito/pull/3132";>mockito/mockito#3132) Bump com.google.googlejavaformat:google-java-format from 1.18.0 to 1.18.1 [(https://redirect.github.com/mockito/mockito/issues/3131";>#3131)](https://redirect.github.com/mockito/mockito/pull/3131";>mockito/mockito#3131) Make MockUtil.getMockMaker() public Mockito API [(https://redirect.github.com/mockito/mockito/issues/3129";>#3129)](https://redirect.github.com/mockito/mockito/pull/3129";>mockito/mockito#3129)
Re: [PR] Bump org.springframework:spring-framework-bom from 6.0.13 to 6.1.0 [logging-log4j-jakarta]
github-actions[bot] commented on PR #4: URL: https://github.com/apache/logging-log4j-jakarta/pull/4#issuecomment-1816983082 Changes are applied by CI in 4ca37fae4e0594bd9dc5ed4e5c069f69faf23df2 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.springframework:spring-framework-bom from 6.0.13 to 6.1.0 [logging-log4j-jakarta]
github-actions[bot] closed pull request #4: Bump org.springframework:spring-framework-bom from 6.0.13 to 6.1.0 URL: https://github.com/apache/logging-log4j-jakarta/pull/4 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.mockito:mockito-bom from 5.5.0 to 5.7.0 [logging-log4j-jakarta]
github-actions[bot] commented on PR #3: URL: https://github.com/apache/logging-log4j-jakarta/pull/3#issuecomment-1816996007 Changes are applied by CI in f6bbf6258ee43d60118cd0a4e1a9fda99a560e28 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.mockito:mockito-bom from 5.5.0 to 5.7.0 [logging-log4j-jakarta]
github-actions[bot] closed pull request #3: Bump org.mockito:mockito-bom from 5.5.0 to 5.7.0 URL: https://github.com/apache/logging-log4j-jakarta/pull/3 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.junit:junit-bom from 5.10.0 to 5.10.1 [logging-log4j-jakarta]
ppkarwasz commented on PR #1: URL: https://github.com/apache/logging-log4j-jakarta/pull/1#issuecomment-1817028310 @dependabot recreate -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.junit:junit-bom from 5.10.0 to 5.10.1 [logging-log4j-jakarta]
github-actions[bot] closed pull request #1: Bump org.junit:junit-bom from 5.10.0 to 5.10.1 URL: https://github.com/apache/logging-log4j-jakarta/pull/1 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.junit:junit-bom from 5.10.0 to 5.10.1 [logging-log4j-jakarta]
github-actions[bot] commented on PR #1: URL: https://github.com/apache/logging-log4j-jakarta/pull/1#issuecomment-1817035848 Changes are applied by CI in 6fb89eb4d389963b6e5f95fca1ae0cff5bbab592 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.springframework:spring-framework-bom from 6.1.0 to 6.1.1 [logging-log4j-jakarta]
ppkarwasz commented on PR #5: URL: https://github.com/apache/logging-log4j-jakarta/pull/5#issuecomment-1824930468 @dependabot rebase -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.springframework:spring-framework-bom from 6.1.0 to 6.1.1 [logging-log4j-jakarta]
github-actions[bot] commented on PR #5: URL: https://github.com/apache/logging-log4j-jakarta/pull/5#issuecomment-1824937518 Changes are applied by CI in 14a91d49c6fe432e9df0e0b8429d01dbf036bf13 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.springframework:spring-framework-bom from 6.1.0 to 6.1.1 [logging-log4j-jakarta]
github-actions[bot] closed pull request #5: Bump org.springframework:spring-framework-bom from 6.1.0 to 6.1.1 URL: https://github.com/apache/logging-log4j-jakarta/pull/5 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Bump org.apache.logging.log4j:log4j-core from 2.21.1 to 2.22.0 [logging-log4j-jmx-gui]
dependabot[bot] opened a new pull request, #3: URL: https://github.com/apache/logging-log4j-jmx-gui/pull/3 Bumps org.apache.logging.log4j:log4j-core from 2.21.1 to 2.22.0. [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.apache.logging.log4j:log4j-core from 2.21.1 to 2.22.0 [logging-log4j-jmx-gui]
github-actions[bot] commented on PR #3: URL: https://github.com/apache/logging-log4j-jmx-gui/pull/3#issuecomment-1838104741 Changes are applied by CI in 3aeeafbbb80bba1542ed0a38261e79d6cb4d7b26 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.apache.logging.log4j:log4j-core from 2.21.1 to 2.22.0 [logging-log4j-jmx-gui]
dependabot[bot] commented on PR #3: URL: https://github.com/apache/logging-log4j-jmx-gui/pull/3#issuecomment-1838104820 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.apache.logging.log4j:log4j-core from 2.21.1 to 2.22.0 [logging-log4j-jmx-gui]
github-actions[bot] closed pull request #3: Bump org.apache.logging.log4j:log4j-core from 2.21.1 to 2.22.0 URL: https://github.com/apache/logging-log4j-jmx-gui/pull/3 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [D] How do I register a StatusListener in configuration? [logging-log4j2]
GitHub user ppkarwasz added a comment to the discussion: How do I register a StatusListener in configuration? We could probably register status listeners automatically using `ServiceLoader`, which is in practice the only way to ensure that they are registered **before** `StatusLogger` is used for the first time. The behavior could be similar to a JUnit [`LauncherSessionListener`](https://junit.org/junit5/docs/current/user-guide/#launcher-api-launcher-session-listeners-custom). Of course for security reasons, there should also be a configuration property to turn on the auto-registration. Personally, I am open to a PR in this direction. GitHub link: https://github.com/apache/logging-log4j2/discussions/3576#discussioncomment-12644421 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] How do I register a StatusListener in configuration? [logging-log4j2]
GitHub user vy added a comment to the discussion: How do I register a StatusListener in configuration? This is explained in [the Status Logger documentation](https://logging.apache.org/log4j/2.x/manual/status-logger.html#listeners). You need to programmatically do it. GitHub link: https://github.com/apache/logging-log4j2/discussions/3576#discussioncomment-12638488 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] How do I register a StatusListener in configuration? [logging-log4j2]
GitHub user vy edited a comment on the discussion: How do I register a StatusListener in configuration? This is explained in [the Status Logger documentation](https://logging.apache.org/log4j/2.x/manual/status-logger.html#listeners). You need to programmatically do it. This is also stated in the JavaDoc you linked: > You can programmatically register listeners using > `registerListener(StatusListener)` GitHub link: https://github.com/apache/logging-log4j2/discussions/3576#discussioncomment-12638488 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Provide a Layout to StatusLogger [logging-log4j2]
GitHub user ppkarwasz added a comment to the discussion: Provide a Layout to StatusLogger > The error messages are somewhat useful to me as a user, but stack traces from > inside of log4j are only useful for maintainers of the log4j library. There are [options for the date format of status logger](https://logging.apache.org/log4j/2.x/manual/status-logger.html#log4j2.statusLoggerDateFormat), so I wouldn't be against an option that disables stack traces. Feel free to submit a PR. GitHub link: https://github.com/apache/logging-log4j2/discussions/3578#discussioncomment-12644341 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Provide a Layout to StatusLogger [logging-log4j2]
GitHub user voddan added a comment to the discussion: Provide a Layout to StatusLogger I see. That kinda makes sense, however I wish there was a way to at least turn of the stack traces. The error messages are somewhat useful to me as a user, but stack traces from inside of log4j are only useful for maintainers of the log4j library. > avoiding passing the same exception to the status logger in subsequent calls Not applicable to me since my code is not using the status logger directly. GitHub link: https://github.com/apache/logging-log4j2/discussions/3578#discussioncomment-12639808 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Is using %uuid{RANDOM} pattern in JsonTemplateLayout considered garbage-free? [logging-log4j2]
GitHub user ppkarwasz added a comment to the discussion: Is using %uuid{RANDOM}
pattern in JsonTemplateLayout considered garbage-free?
> However, it definitely makes more sense to ensure the UUID is injected into
> the LogEvent before any Appenders process it.
This is the main problem: `%uuid` is a converter and it can not modify the
`LogEvent`. If the same log event is formatted multiple times, each time
> I am not sure why you are assuming only multiple Appenders can cause
> duplicates to occur.
The question is probably, where the duplication occurs. If a log event is
passed to multiple appenders (or twice to the same appender), then `%uuid` will
not be able to identify the duplicates. This was discussed in #3503.
If the duplication occurs in the appender logic (e.g. it is cause by network
retries), then sure, `%uuid` will help.
GitHub link:
https://github.com/apache/logging-log4j2/discussions/3585#discussioncomment-12762864
This is an automatically sent email for dev@logging.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Is using %uuid{RANDOM} pattern in JsonTemplateLayout considered garbage-free? [logging-log4j2]
GitHub user rgoers added a comment to the discussion: Is using %uuid{RANDOM}
pattern in JsonTemplateLayout considered garbage-free?
I would need to read more on the subject but I have to assume this is very
similar to the problem I faced with Flume. It guarantees delivery but it
doesn't guarantee an event won't be delivered multiple times. This is solved by
providing a unique id. Log4j's TimeBased UUID solves this problem by adding a
unique id when the event is created. Whether there are multiple appenders or
not only matters depending on where they are trying to deliver the data.
However, it definitely makes more sense to ensure the UUID is injected into the
LogEvent before any Appenders process it.
I am not sure why you are assuming only multiple Appenders can cause duplicates
to occur.
GitHub link:
https://github.com/apache/logging-log4j2/discussions/3585#discussioncomment-12757187
This is an automatically sent email for dev@logging.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Is using %uuid{RANDOM} pattern in JsonTemplateLayout considered garbage-free? [logging-log4j2]
GitHub user rgoers added a comment to the discussion: Is using %uuid{RANDOM}
pattern in JsonTemplateLayout considered garbage-free?
I hate to disagree Piotr, but our time based uuid exists for exactly this use
case. It will provide a unique value across all servers. While it isn’t going
to be unique forever, the length of time it is guaranteed to be unique should
be sufficient for virtually any use case.
GitHub link:
https://github.com/apache/logging-log4j2/discussions/3585#discussioncomment-12749819
This is an automatically sent email for dev@logging.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Is using %uuid{RANDOM} pattern in JsonTemplateLayout considered garbage-free? [logging-log4j2]
GitHub user ppkarwasz added a comment to the discussion: Is using %uuid{RANDOM}
pattern in JsonTemplateLayout considered garbage-free?
Neither one is GC-free. Each one will create an instance of
[`UUID`](https://docs.oracle.com/javase/8/docs/api/java/util/UUID.html) and
`String`. Scalar replacement might occur, when the JVM is hot enough, but you
should test it on a concrete version of the JVM.
GitHub link:
https://github.com/apache/logging-log4j2/discussions/3585#discussioncomment-12696831
This is an automatically sent email for dev@logging.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Is using %uuid{RANDOM} pattern in JsonTemplateLayout considered garbage-free? [logging-log4j2]
GitHub user ppkarwasz added a comment to the discussion: Is using %uuid{RANDOM}
pattern in JsonTemplateLayout considered garbage-free?
**BTW**: Using `%uuid` as value for
[logging.googleapis.com/insertId](https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry#FIELDS.insert_id)
does not fulfill the **unicity** requirement from the documentation:
> _Optional_. A unique identifier for the log entry. If you provide a value,
> then Logging considers other log entries in the same project, with the same
> timestamp, and with the same `insertId` to be duplicates which are removed in
> a single query result. However, there are no guarantees of de-duplication in
> the export of logs.
> If the `insertId` is omitted when writing a log entry, the Logging API
> assigns its own unique identifier in this field.
The same log event, delivered by different appenders will have different UUIDs.
See #3503 for a discussion.
GitHub link:
https://github.com/apache/logging-log4j2/discussions/3585#discussioncomment-12696880
This is an automatically sent email for dev@logging.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] TimeBasedTriggeringPolicy and CronTriggeringPolicy [logging-log4j2]
GitHub user Class-New added a comment to the discussion: TimeBasedTriggeringPolicy and CronTriggeringPolicy Because the project wants to roll the daily logs under the corresponding date directory, for example, the logs that occurred on 2025-04-02 are rolled under the folder 2025-04-02. But what I have learned is that the trigger policy of TimeBasedTriggeringPolic is that it will roll only when the next log event arrives, so if no log comes, it will not be archived, so it will be processed at 0 am every day like combining CronTriggeringPolicy GitHub link: https://github.com/apache/logging-log4j2/discussions/3587#discussioncomment-12744563 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] TimeBasedTriggeringPolicy and CronTriggeringPolicy [logging-log4j2]
GitHub user ppkarwasz added a comment to the discussion: TimeBasedTriggeringPolicy and CronTriggeringPolicy @Class-New, As [documented on our website](https://logging.apache.org/log4j/2.x/manual/appenders/rolling-file.html#Policies): > The effects of using **both** time-based triggering policies > ([CronTriggeringPolicy](https://logging.apache.org/log4j/2.x/manual/appenders/rolling-file.html#CronTriggeringPolicy) > and > [TimeBasedTriggeringPolicy](https://logging.apache.org/log4j/2.x/manual/appenders/rolling-file.html#TimeBasedTriggeringPolicy)) > at the same time are undefined. GitHub link: https://github.com/apache/logging-log4j2/discussions/3587#discussioncomment-12747441 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Is using %uuid{RANDOM} pattern in JsonTemplateLayout considered garbage-free? [logging-log4j2]
GitHub user ppkarwasz added a comment to the discussion: Is using %uuid{RANDOM}
pattern in JsonTemplateLayout considered garbage-free?
I am not saying that `%uuid` will give the **same** value for **different** log
events, but that it will give **different** value for the **same** log event if
they are delivered by different appenders.
GCP says:
> If you provide a value, then Logging considers other log entries in the same
> project, with the same timestamp, and with the same `insertId` to be
> duplicates which are removed in a single query result.
Since each time the same log event is formatted, another UUID is generated,
every `insertId` will be different and no duplicate events will be merged.
GitHub link:
https://github.com/apache/logging-log4j2/discussions/3585#discussioncomment-12753158
This is an automatically sent email for dev@logging.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Custom rewrite appender not working when used like dependency on spring boot app [logging-log4j2]
GitHub user vy added a comment to the discussion: Custom rewrite appender not working when used like dependency on spring boot app Project A has a dependency on Project B, which contains a custom appender, that you want to use in the `log4j2.xml` of Project A, right? 1. How do you package Project B? Is it just a regular library JAR? 2. How do you _import_ Project B into Project A? As a regular Maven/Gradle dependency? 3. You've read [Extending appenders](https://logging.apache.org/log4j/2.x/manual/appenders.html#extending) and using the [PluginProcessor](https://logging.apache.org/log4j/2.x/javadoc/log4j-core/org/apache/logging/log4j/core/config/plugins/processor/PluginProcessor.html) annotation processor while building the Project B, right? GitHub link: https://github.com/apache/logging-log4j2/discussions/3611#discussioncomment-12854522 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Need help on migrating from PluginManager to PluginProcessor [logging-log4j2]
GitHub user vy added a comment to the discussion: Need help on migrating from PluginManager to PluginProcessor @VenkataSubbareddy-GY, when you compile your code using the annotation processor, do you see a `Log4j2Plugins.dat` gets auto-generated? Does it contain your custom plugins? GitHub link: https://github.com/apache/logging-log4j2/discussions/3573#discussioncomment-12821689 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] TimeBasedTriggeringPolicy and CronTriggeringPolicy [logging-log4j2]
GitHub user Class-New added a comment to the discussion: TimeBasedTriggeringPolicy and CronTriggeringPolicy Thank you for your answer GitHub link: https://github.com/apache/logging-log4j2/discussions/3587#discussioncomment-12861070 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] How do I register a StatusListener in configuration? [logging-log4j2]
GitHub user voddan added a comment to the discussion: How do I register a StatusListener in configuration? @vy How would it look in a project? If you can share an example project where you do it like that, it would be great. Simply put, I don't understand where I should put this line of code `statusLogger.registerListener(StatusListener)`, considering that I can't put it into the code of the app. GitHub link: https://github.com/apache/logging-log4j2/discussions/3576#discussioncomment-12639233 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Provide a Layout to StatusLogger [logging-log4j2]
GitHub user vy added a comment to the discussion: Provide a Layout to StatusLogger No, it is not possible and, IMHO, this is a good thing. Status Logger is the logger for the logger – that is, we need to keep its feature set at minimum. Consider it like a `printf()` on steroids. > When I get networking problems with my appender, it prints elaborate error > messages with extensive stack traces If this is an unexpected failure, it is good to point to the user the origin by means of a stack trace. If this is something regular, you might consider either introducing a rate limiter to the error messages you emit, or avoiding passing the same exception to the status logger in subsequent calls. GitHub link: https://github.com/apache/logging-log4j2/discussions/3578#discussioncomment-12638574 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] How do I register a StatusListener in configuration? [logging-log4j2]
GitHub user vy added a comment to the discussion: How do I register a
StatusListener in configuration?
```
StatusLogger.getLogger().registerListener(...)
```
You need to place this snippet as early as possible in your application
initialization, e.g.,
```
static {
StatusLogger.getLogger().registerListener(...)
}
public static void main(String[] args) { ... }
```
GitHub link:
https://github.com/apache/logging-log4j2/discussions/3576#discussioncomment-12639529
This is an automatically sent email for dev@logging.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Is using %uuid{RANDOM} pattern in JsonTemplateLayout considered garbage-free? [logging-log4j2]
GitHub user ViliusS edited a comment on the discussion: Is using %uuid{RANDOM}
pattern in JsonTemplateLayout considered garbage-free?
> **BTW**: Using `%uuid` as value for
> [logging.googleapis.com/insertId](https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry#FIELDS.insert_id)
> does not fulfill the **unicity** requirement from the documentation:
>
> > _Optional_. A unique identifier for the log entry. If you provide a value,
> > then Logging considers other log entries in the same project, with the same
> > timestamp, and with the same `insertId` to be duplicates which are removed
> > in a single query result. However, there are no guarantees of
> > de-duplication in the export of logs.
> > If the `insertId` is omitted when writing a log entry, the Logging API
> > assigns its own unique identifier in this field.
>
> The same log event, delivered by different appenders will have different
> UUIDs. See #3503 for a discussion.
I'm going to propose PR for GcpLayout.json template shortly. Among other
things, counter cannot be used with `logging.googleapis.com/insertId` either
because it produces duplicate IDs for different JVM threads. It also restarts
from ID 1 if Java application is restarted.
I think having different UUID for different appenders are exactly how it is
supposed to work. Different appenders pushing to the same Google Cloud Log
would probably mean different log event formatting anyway, so we should ensure
that such messages are no de-duplicated by GCP.
Alternatively, `insertId` could be omitted completely, so GCP would generate
their own IDs.
GitHub link:
https://github.com/apache/logging-log4j2/discussions/3585#discussioncomment-12698772
This is an automatically sent email for dev@logging.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Is using %uuid{RANDOM} pattern in JsonTemplateLayout considered garbage-free? [logging-log4j2]
GitHub user ViliusS edited a comment on the discussion: Is using %uuid{RANDOM}
pattern in JsonTemplateLayout considered garbage-free?
> **BTW**: Using `%uuid` as value for
> [logging.googleapis.com/insertId](https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry#FIELDS.insert_id)
> does not fulfill the **unicity** requirement from the documentation:
>
> > _Optional_. A unique identifier for the log entry. If you provide a value,
> > then Logging considers other log entries in the same project, with the same
> > timestamp, and with the same `insertId` to be duplicates which are removed
> > in a single query result. However, there are no guarantees of
> > de-duplication in the export of logs.
> > If the `insertId` is omitted when writing a log entry, the Logging API
> > assigns its own unique identifier in this field.
>
> The same log event, delivered by different appenders will have different
> UUIDs. See #3503 for a discussion.
I'm going to propose PR for GcpLayout.json template shortly. Among other
things, counter cannot be used with `logging.googleapis.com/insertId` either
because it produces duplicate IDs for different JVM threads. It also restarts
if Java application is restarted.
I think having different UUID for different appenders are exactly how it is
supposed to work. Different appenders pushing to the same Google Cloud Log
would probably mean different log event formatting anyway, so we should ensure
that such messages are no de-duplicated by GCP.
Alternatively, `insertId` could be omitted completely, so GCP would generate
their own IDs.
GitHub link:
https://github.com/apache/logging-log4j2/discussions/3585#discussioncomment-12698772
This is an automatically sent email for dev@logging.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Is using %uuid{RANDOM} pattern in JsonTemplateLayout considered garbage-free? [logging-log4j2]
GitHub user ppkarwasz added a comment to the discussion: Is using %uuid{RANDOM}
pattern in JsonTemplateLayout considered garbage-free?
> Alternatively, `insertId` could be omitted completely, so GCP would generate
> their own IDs.
This is probably the route I would choose. The only purpose of this value is to
deduplicate log events with the **same timestamp**. Short of creating a
`ContextDataProvider` with a counter, I don't see a reliable way to do that.
Log duplication shouldn't occur anyway, except misconfigurations like:
```xml
```
GitHub link:
https://github.com/apache/logging-log4j2/discussions/3585#discussioncomment-12699365
This is an automatically sent email for dev@logging.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Is using %uuid{RANDOM} pattern in JsonTemplateLayout considered garbage-free? [logging-log4j2]
GitHub user ViliusS edited a comment on the discussion: Is using %uuid{RANDOM}
pattern in JsonTemplateLayout considered garbage-free?
> **BTW**: Using `%uuid` as value for
> [logging.googleapis.com/insertId](https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry#FIELDS.insert_id)
> does not fulfill the **unicity** requirement from the documentation:
>
> > _Optional_. A unique identifier for the log entry. If you provide a value,
> > then Logging considers other log entries in the same project, with the same
> > timestamp, and with the same `insertId` to be duplicates which are removed
> > in a single query result. However, there are no guarantees of
> > de-duplication in the export of logs.
> > If the `insertId` is omitted when writing a log entry, the Logging API
> > assigns its own unique identifier in this field.
>
> The same log event, delivered by different appenders will have different
> UUIDs. See #3503 for a discussion.
I'm going to propose PR for GcpLayout.json template shortly. Among other
things, counter cannot be used with `logging.googleapis.com/insertId` either
because it produces duplicate IDs for different JVM threads. It also restarts
from ID 1 if Java application is restarted.
I think having different UUID for different appenders are exactly how it is
supposed to work. Different appenders pushing to the same Google Cloud Log
would probably mean different log event formatting anyway, so we should ensure
that such messages are not de-duplicated by GCP.
Alternatively, `insertId` could be omitted completely, so GCP would generate
their own IDs.
GitHub link:
https://github.com/apache/logging-log4j2/discussions/3585#discussioncomment-12698772
This is an automatically sent email for dev@logging.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Is using %uuid{RANDOM} pattern in JsonTemplateLayout considered garbage-free? [logging-log4j2]
GitHub user ViliusS added a comment to the discussion: Is using %uuid{RANDOM}
pattern in JsonTemplateLayout considered garbage-free?
> **BTW**: Using `%uuid` as value for
> [logging.googleapis.com/insertId](https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry#FIELDS.insert_id)
> does not fulfill the **unicity** requirement from the documentation:
>
> > _Optional_. A unique identifier for the log entry. If you provide a value,
> > then Logging considers other log entries in the same project, with the same
> > timestamp, and with the same `insertId` to be duplicates which are removed
> > in a single query result. However, there are no guarantees of
> > de-duplication in the export of logs.
> > If the `insertId` is omitted when writing a log entry, the Logging API
> > assigns its own unique identifier in this field.
>
> The same log event, delivered by different appenders will have different
> UUIDs. See #3503 for a discussion.
I'm going to propose PR for GcpLayout.json template shortly. Among other
things, counter cannot be used with `logging.googleapis.com/insertId` either
because it produces duplicate IDs for different JVM threads. It also restarts
if Java application is restarted.
I think having different UUID for different appenders are exactly how it is
supposed to work. Different appenders pushing to the same Google Cloud Log
would probably mean different log event formatting anyway, so we should ensure
that such messages are no de-duplicated by GCP.
GitHub link:
https://github.com/apache/logging-log4j2/discussions/3585#discussioncomment-12698772
This is an automatically sent email for dev@logging.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] log4j-1.2.13.jar substitution in v.2.17.1 [logging-log4j2]
GitHub user ElaHuskovic68 edited a discussion: log4j-1.2.13.jar substitution in v.2.17.1 Inside war file at path /WEB-INF/lib we found log4j-1.2.13 which needs to be replaced with log4j-2.17.1.jar. In apache-log4j-2.17.1-bin there is no that file. What jar file replaces old one? Thanks! GitHub link: https://github.com/apache/logging-log4j2/discussions/3656 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] log4j-1.2.13.jar substitution in v.2.17.1 [logging-log4j2]
GitHub user ElaHuskovic68 added a comment to the discussion: log4j-1.2.13.jar substitution in v.2.17.1 Not in our case. We though just to replace .jar file but no proper match in higher version. GitHub link: https://github.com/apache/logging-log4j2/discussions/3656#discussioncomment-13091702 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] log4j-1.2.13.jar substitution in v.2.17.1 [logging-log4j2]
GitHub user vy added a comment to the discussion: log4j-1.2.13.jar substitution in v.2.17.1 @ElaHuskovic68, does the [Migrating from Log4j 1](https://logging.apache.org/log4j/2.x/migrate-from-log4j1.html) page help? GitHub link: https://github.com/apache/logging-log4j2/discussions/3656#discussioncomment-13091282 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] log4j-1.2.13.jar substitution in v.2.17.1 [logging-log4j2]
GitHub user ppkarwasz added a comment to the discussion: log4j-1.2.13.jar substitution in v.2.17.1 Can you provide us with some feedback on the migration page? Where does it come short of your expectations? To better understand, how we can help, can you tell us: - Do you have access to the source code of the application or is it a third-party application? - If it is a third-party application, is the producer still around? - Why did you choose to upgrade to `2.17.1` instead of the currently supported (`2.24.x`) version? GitHub link: https://github.com/apache/logging-log4j2/discussions/3656#discussioncomment-13102199 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Question about asynchronous writing by log4net [logging-log4net]
GitHub user FreeAndNil added a comment to the discussion: Question about asynchronous writing by log4net @yktnoriri I've converted you issue into a discussion. I was able to reproduce your problem once, but only once. Can you set a breakpoint in https://github.com/apache/logging-log4net/blob/172e875622c0d4ba845ad6dace02c001687de96f/src/log4net/Appender/RollingFileAppender.cs#L634 and add a condition for the "wrong" fileName? GitHub link: https://github.com/apache/logging-log4net/discussions/243#discussioncomment-13085717 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] log4j-1.2.13.jar substitution in v.2.17.1 [logging-log4j2]
GitHub user ElaHuskovic68 added a comment to the discussion: log4j-1.2.13.jar substitution in v.2.17.1 hi @ppkarwasz - thank you for your answer. This is third party application, I dont have source code, only war file which contains 1.x version of log4j jar file. I checked with Owner and it looks like it wont work with newer jar file, proper migration has to be done from their end. Due to vulnerability of log4j it is recommended to upgrade on new version. Since I already have application with log4j 2.17.1 - though it could be the same version. Anyway, thanks for your reply. GitHub link: https://github.com/apache/logging-log4j2/discussions/3656#discussioncomment-13134691 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] log4j-1.2.13.jar substitution in v.2.17.1 [logging-log4j2]
GitHub user perry2of5 added a comment to the discussion: log4j-1.2.13.jar substitution in v.2.17.1 Some people have been known to recommend Reload4j 1.2.18 as a replacement for log4j 1.2.17 GitHub link: https://github.com/apache/logging-log4j2/discussions/3656#discussioncomment-13135934 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] log4j-1.2.13.jar substitution in v.2.17.1 [logging-log4j2]
GitHub user lalo-mx added a comment to the discussion: log4j-1.2.13.jar substitution in v.2.17.1 > Some people have been known to recommend Reload4j 1.2.18 as a replacement for > log4j 1.2.17 https://reload4j.qos.ch/ > Initiated by Ceki Gülcü, the original author of Apache log4j 1.x, the > reload4j project is a fork of Apache log4j version 1.2.17 with the goal of > fixing pressing security issues. Reload4j is a binary compatible, drop-in > replacement for log4j version 1.2.17. By drop-in, we mean that you can > replace log4j.jar with reload4j.jar in your build with no source code > changes, no recompilation, nor rebuild being necessary. > > The reload4j project offers a clear and easy migration path for the thousands > of users who have an urgent need to fix vulnerabilities in log4j 1.2.17. GitHub link: https://github.com/apache/logging-log4j2/discussions/3656#discussioncomment-13136008 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] log4j-1.2.13.jar substitution in v.2.17.1 [logging-log4j2]
GitHub user ppkarwasz edited a comment on the discussion: log4j-1.2.13.jar substitution in v.2.17.1 @ElaHuskovic68, > This is third party application, I dont have source code, only war file which > contains 1.x version of log4j jar file. Thanks for clarifying your situation — dealing with third-party applications can be tricky, especially when you're limited to what's inside a WAR file. You're right that our migration guide is primarily geared toward developers who can modify application code. For deployers like yourself, who need to assess risk without modifying the source, the relevant details are available but admittedly not easy to navigate. You're very welcome to suggest improvements or a dedicated section — we’d appreciate the contribution! In your case, where you're dealing with Log4j 1.x embedded in a third-party WAR, you have a few practical options: ### Assess Exploitability — Not Just Vulnerability Security scanners often flag known CVEs without determining if they’re **actually exploitable** in your setup. You can use this to your advantage by verifying whether the risky components are even in use. Here’s a quick guide to the known Log4j 1.x vulnerabilities and when they’re actually exploitable: | CVE ID | Exploitable When... | ||---| | CVE-2019-17571 | Only in the unlikely case the application launches `SocketServer`, e.g.: `java -jar log4j.jar org.apache.log4j.net.SocketServer` | | CVE-2020-9488 | If the app uses `SMTPAppender` | | CVE-2021-4104 | If the app uses `JMSAppender` | | CVE-2022-23302 | If the app uses `JMSAppender` | | CVE-2022-23305 | If the app uses `JDBCAppender` | To determine if a vulnerability applies to your setup, you can inspect the `log4j.properties` or `log4j.xml` file. Since you already notified the producer of the application and they are working on a solution, I believe this is the right approach. In the coming years you'll see many vulnerabilities, like Tomcat's CVE-2025-24813, that are not exploitable in almost any environment, but cause panic to the system administrator community. **Note**: I am not encouraging **developers** to use **EOL** libraries. These libraries have a much higher risk of undisclosed vulnerabilities, since nobody is reporting them and nobody is accepting the reports. ### Upgrade to a Newer Logging Backend Using the Log4j 1.x Bridge If you want to modernize the logging system without modifying the application code (since you only have a WAR file), you can use the Log4j 1.x Bridge. This allows applications built with Log4j 1.x to log through the Log4j 2.x backend. While not a long-term solution for full migrations, it’s often a practical and low-effort approach for third-party applications where source code isn’t available. How to Set It Up: 1. Remove the old log4j.jar from the WAR file. 2. Add the following Log4j jars: - `log4j-1.2-api.jar`(the bridge) - `log4j-api.jar` (Log4j 2 API) - A [Log4j API implementation](https://logging.apache.org/log4j/2.x/manual/installation.html#impl), in your case `log4j-core.jar` 3. Provide a Log4j 2 configuration file, in your case `log4j2.xml`, placed in the classpath (e.g., inside `WEB-INF/classes`). > [!NOTE] > The bridge supports [automatic conversion of some Log4j 1.x > configurations](https://logging.apache.org/log4j/2.x/migrate-from-log4j1.html#ConfigurationCompatibility). If you set the system property `log4j1.compatibility=true`, it can interpret Log4j 1.x configuration files (like `log4j.properties`) at runtime. > > However, for best results and to unlock the full power of Log4j Core, we > recommend to switch to a native Log4j 2 configuration format. GitHub link: https://github.com/apache/logging-log4j2/discussions/3656#discussioncomment-13141001 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] log4j-1.2.13.jar substitution in v.2.17.1 [logging-log4j2]
GitHub user ppkarwasz added a comment to the discussion: log4j-1.2.13.jar substitution in v.2.17.1 @ElaHuskovic68, > This is third party application, I dont have source code, only war file which > contains 1.x version of log4j jar file. Thanks for clarifying your situation — dealing with third-party applications can be tricky, especially when you're limited to what's inside a WAR file. You're right that our migration guide is primarily geared toward developers who can modify application code. For deployers like yourself, who need to assess risk without modifying the source, the relevant details are available but admittedly not easy to navigate. You're very welcome to suggest improvements or a dedicated section — we’d appreciate the contribution! In your case, where you're dealing with Log4j 1.x embedded in a third-party WAR, you have a few practical options: ### Assess Exploitability — Not Just Vulnerability Security scanners often flag known CVEs without determining if they’re **actually exploitable** in your setup. You can use this to your advantage by verifying whether the risky components are even in use. Here’s a quick guide to the known Log4j 1.x vulnerabilities and when they’re actually exploitable: | CVE ID | Exploitable When... | ||---| | CVE-2019-17571 | Only in the unlikely case the application launches `SocketServer`, e.g.: `java -jar log4j.jar org.apache.log4j.net.SocketServer` | | CVE-2020-9488 | If the app uses `SMTPAppender` | | CVE-2021-4104 | If the app uses `JMSAppender` | | CVE-2022-23302 | If the app uses `JMSAppender` | | CVE-2022-23305 | If the app uses `JDBCAppender` | To determine if a vulnerability applies to your setup, you can inspect the `log4j.properties` or `log4j.xml` file. Since you already notified the producer of the application and they are working on a solution, I believe this is the right approach. In the coming years you'll see many vulnerabilities, like Tomcat's CVE-2025-24813, that are not exploitable in almost any environment, but cause panic to the system administrator community. **Note**: I am not encouraging **developers** to use **EOL** libraries. These libraries have a much higher risk of undisclosed vulnerabilities, since nobody is reporting them and nobody is accepting the reports. ### Upgrade to a Newer Logging Backend Using the Log4j 1.x Bridge If you want to modernize the logging system without modifying the application code (since you only have a WAR file), you can use the Log4j 1.x Bridge. This allows applications built with Log4j 1.x to log through the Log4j 2.x backend. While not a long-term solution for full migrations, it’s often a practical and low-effort approach for third-party applications where source code isn’t available. How to Set It Up: 1. Remove the old log4j.jar from the WAR file. 2. Add the following Log4j 2 jars: - `log4j-1.2-api.jar`(the bridge) - `log4j-api.jar` (Log4j 2 API) - A [Log4j API implementation](https://logging.apache.org/log4j/2.x/manual/installation.html#impl), in your case `log4j-core.jar` 3. Provide a Log4j 2 configuration file, in your case `log4j2.xml`, placed in the classpath (e.g., inside `WEB-INF/classes`). > [!NOTE] > The bridge supports [automatic conversion of some Log4j 1.x > configurations](https://logging.apache.org/log4j/2.x/migrate-from-log4j1.html#ConfigurationCompatibility). If you set the system property log4j1.compatibility=true, it can interpret Log4j 1.x configuration files (like log4j.properties) at runtime. > > However, for best results and to unlock the full power of Log4j Core, it’s > recommended to switch to a native Log4j 2 configuration format. GitHub link: https://github.com/apache/logging-log4j2/discussions/3656#discussioncomment-13141001 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] log4j-1.2.13.jar substitution in v.2.17.1 [logging-log4j2]
GitHub user ppkarwasz added a comment to the discussion: log4j-1.2.13.jar substitution in v.2.17.1 Reload4j is a **valid temporary** replacement for Log4j 1, and I can certainly recommend it for that purpose. While it introduces some breaking changes compared to Log4j `1.2.17`, it is **99% binary compatible** with it, making it a suitable choice for immediate mitigation. For completeness, there are other maintained forks of Log4j 1: - Versions of Log4j 1 available in the [JBoss Enterprise Maven Repository](https://access.redhat.com/maven-repository), such as `1.2.17.redhat-8`. - Versions available in the [Atlassian Maven Repository](https://developer.atlassian.com/server/framework/atlassian-sdk/atlassian-maven-repositories-2818705/), like `1.2.17-atlassian-18`. Although the release notes for these versions are not publicly available, it’s likely that they address some, if not all, of the known vulnerabilities in the official `1.2.17 `release. If you're an Atlassian or Red Hat customer, it’s worth reaching out to their technical support for more information. GitHub link: https://github.com/apache/logging-log4j2/discussions/3656#discussioncomment-13143017 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] log4j version 2.17.1 [logging-log4j2]
GitHub user mmahant17 added a comment to the discussion: log4j version 2.17.1 Thank you for your prompt response. GitHub link: https://github.com/apache/logging-log4j2/discussions/3679#discussioncomment-13212196 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] log4j version 2.17.1 [logging-log4j2]
GitHub user ppkarwasz added a comment to the discussion: log4j version 2.17.1 > Could you please confirm if Log4j version 2.17.1 is supported? Whether we "support" Log4j version `2.17.0` depends on how you define "support," so let’s break it down: - We **no longer** maintain the `2.17.x` minor version. Only the latest release within the `2.x` series receives updates — including security fixes. If a vulnerability is discovered, you'll need to upgrade to the latest `2.x` version or patch `2.17.x` yourself. - We do **not** accept bug reports for `2.17.x`. All issues must be reproducible in the latest available version. - We **do** accept security vulnerability reports affecting `2.17.x`, and we will publish a security advisory if needed. However, as noted above, we will not release new patches for the `2.17.x` line. - [**Community support**](https://logging.apache.org/support.html#discussions-user) remains **available** on a best-effort basis. We even occasionally answer questions about Log4j 1.x — if someone remembers how it worked! - For guaranteed support with SLAs, some companies offer [**commercial support**](https://logging.apache.org/support.html#commercial) for Log4j. GitHub link: https://github.com/apache/logging-log4j2/discussions/3679#discussioncomment-13212261 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] log4j version 2.17.1 [logging-log4j2]
GitHub user ppkarwasz edited a comment on the discussion: log4j version 2.17.1 > Could you please confirm if Log4j version 2.17.1 is supported? Whether we "support" Log4j version `2.17.0` depends on how you define "support," so let’s break it down: - We **no longer** maintain the `2.17.x` minor version. Only the latest release within the `2.x` series receives updates — including security fixes. If a vulnerability is discovered, you'll need to upgrade to the latest `2.x` version or patch `2.17.x` yourself. - We do **not** accept bug reports for `2.17.x`. All issues must be reproducible in the latest available version. - We **do** accept security vulnerability reports affecting `2.17.x`, and we will publish a security advisory if needed. However, as noted above, we will not release new patches for the `2.17.x` line. - [**Community support**](https://logging.apache.org/support.html#discussions-user) remains **available** on a best-effort basis. We even occasionally answer questions about Log4j 1.x — if someone remembers how it worked! :stuck_out_tongue_closed_eyes: - For guaranteed support with SLAs, some companies offer [**commercial support**](https://logging.apache.org/support.html#commercial) for Log4j. GitHub link: https://github.com/apache/logging-log4j2/discussions/3679#discussioncomment-13212261 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] log4j version 2.17.1 [logging-log4j2]
GitHub user ppkarwasz added a comment to the discussion: log4j version 2.17.1 That’s an excellent answer — thank you! Just to add for completeness: version 2.17.0 was never affected by CVE-2021-44832. This was confirmed in a later review (see apache/logging-site#6). GitHub link: https://github.com/apache/logging-log4j2/discussions/3679#discussioncomment-13212117 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] log4j version 2.17.1 [logging-log4j2]
GitHub user perry2of5 added a comment to the discussion: log4j version 2.17.1 Please refer to the security page: https://logging.apache.org/security.html Also, mvnrepository.com provides links to most security vulnerabilities from affected artifacts. For example, on log4j-core, it doesn't show any vulnerabilities on versions after 2.17.0 https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core GitHub link: https://github.com/apache/logging-log4j2/discussions/3679#discussioncomment-13211970 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? [logging-log4j2]
GitHub user ppkarwasz added a comment to the discussion: Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? You can follow the progress of release `2.25.0` in [its dedicated mailing list thread](https://lists.apache.org/thread/9gshmgk75llkzvmns6ocks1b5h7n90qp). GitHub link: https://github.com/apache/logging-log4j2/discussions/3682#discussioncomment-13264358 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? [logging-log4j2]
GitHub user jluehe edited a comment on the discussion: Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? Created Issue https://github.com/apache/logging-log4j2/issues/3686 GitHub link: https://github.com/apache/logging-log4j2/discussions/3682#discussioncomment-13255364 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? [logging-log4j2]
GitHub user jluehe edited a comment on the discussion: Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? @ppkarwasz, for your review: https://github.com/apache/logging-log4j2/pull/3689 GitHub link: https://github.com/apache/logging-log4j2/discussions/3682#discussioncomment-13255405 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Question about asynchronous writing by log4net [logging-log4net]
GitHub user yktnoriri closed a discussion: Question about asynchronous writing by log4net Hello there, We are currently using log4net for logging in our .NET Framework 4.8 application, developed with Microsoft Visual Studio Professional 2022 Version 17.12.3. We have observed a potential issue where, when writing to a log file asynchronously, the resulting log file sometimes gets output with a duplicated file name (e.g., logfile.log.logfile.log). We have prepared a logging configuration that mirrors our internal source code, and while we haven't been able to reproduce the issue consistently in our local testing environment, the same process in our production environment has exhibited this behavior. We are seeking your expertise on potential causes for this duplicated file naming issue specifically in asynchronous logging scenarios within the described environment. Any insights or suggestions for investigation would be greatly appreciated. Sincerely, [ConsoleApp.zip](https://github.com/user-attachments/files/20116379/ConsoleApp.zip) GitHub link: https://github.com/apache/logging-log4net/discussions/243 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Question about asynchronous writing by log4net [logging-log4net]
GitHub user FreeAndNil closed the discussion with a comment: Question about asynchronous writing by log4net Please reopen when you find the time to respond. GitHub link: https://github.com/apache/logging-log4net/discussions/243#discussioncomment-13275414 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? [logging-log4j2]
GitHub user jluehe edited a comment on the discussion: Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? @ppkarwasz, for your review: https://github.com/apache/logging-log4j2/pull/3690 GitHub link: https://github.com/apache/logging-log4j2/discussions/3682#discussioncomment-13255405 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? [logging-log4j2]
GitHub user jluehe added a comment to the discussion: Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? @ppkarwasz, can you tell me what is the ETA for the `2.25.0` release? Thanks! GitHub link: https://github.com/apache/logging-log4j2/discussions/3682#discussioncomment-13262982 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? [logging-log4j2]
GitHub user jluehe edited a comment on the discussion: Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? @ppkarwasz, can you tell me what is the ETA for the `2.25.0` release? Even an approximate date would help! Thanks! GitHub link: https://github.com/apache/logging-log4j2/discussions/3682#discussioncomment-13262982 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Parameterized Info intermittently throws IllegalArgumentException [logging-log4j2]
GitHub user ppkarwasz added a comment to the discussion: Parameterized Info intermittently throws IllegalArgumentException @arbardhan, Did you test with the latest release (`2.24.3`)? GitHub link: https://github.com/apache/logging-log4j2/discussions/3695#discussioncomment-13288046 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Parameterized Info intermittently throws IllegalArgumentException [logging-log4j2]
GitHub user ppkarwasz added a comment to the discussion: Parameterized Info
intermittently throws IllegalArgumentException
> But can you think of scenarios where this may occur ?
In version `2.21.0`, the parameter formatting logic was changed to **strictly
enforce** a match between `{}` placeholders and arguments—throwing an exception
on mismatch. This broke backward compatibility. The original lenient behavior
was **restored in version `2.24.0`** (see #2380).
As for the cause of the mismatch: could you share your logging statement and
the API you're using? The Log4j API supports up to 10 arguments before
switching to **varargs**, while others switch to varargs much sooner. I suspect
that varargs arguments might be trimmed by some logging bridge.
> 2.24.3 is not available under our org enterprise distribution yet - pending
> approval.
Could you share more about your upgrade policy? I’m currently working with the
**non-profit** [Open Source Economy](https://www.open-source-economy.com/) to
explore the feasibility of supporting multiple minor Log4j versions
simultaneously. Right now, all Log4j maintainers are volunteers, so we can only
support the latest version. However, with funding from OSE’s clients, we could
potentially take on broader Log4j maintenance as part of our regular work.
GitHub link:
https://github.com/apache/logging-log4j2/discussions/3695#discussioncomment-13292909
This is an automatically sent email for dev@logging.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Parameterized Info intermittently throws IllegalArgumentException [logging-log4j2]
GitHub user arbardhan edited a discussion: Parameterized Info intermittently
throws IllegalArgumentException
I log 8 parameters using {} in log.info this comes from a httpServlet request
preHandlePath. This log statement sometimes throwa IAE exception stating only 5
arguments provided for 8 placeholders.
I do evaluate some expressions onFly. Tried dumping them as String in a
variable and then print - no luck.
Using 2.23.1
GitHub link: https://github.com/apache/logging-log4j2/discussions/3695
This is an automatically sent email for dev@logging.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Parameterized Info intermittently throws IllegalArgumentException [logging-log4j2]
GitHub user arbardhan added a comment to the discussion: Parameterized Info intermittently throws IllegalArgumentException 2.24.3 is not available under our org enterprise distribution yet - pending approval. We only go back to older versions. But can you think of scenarios where this may occur ? GitHub link: https://github.com/apache/logging-log4j2/discussions/3695#discussioncomment-13291685 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? [logging-log4j2]
GitHub user ppkarwasz added a comment to the discussion: Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? Thank you for the clarification. As far as I’m aware, the Log4j API itself doesn’t directly depend on Java EE 8 or Jakarta EE 9 APIs. Could you point to the specific usage or class reference you’re seeing that causes compatibility issues? One area that may be causing confusion is the use of the `Servlet` class in a heuristic used to determine if the application is running in a web environment. This is part of setting the default value for the `log4j2.isWebapp` system property: https://github.com/apache/logging-log4j2/blob/2bc484c30d7ca52606ccd185584acf513417a755/log4j-api/src/main/java/org/apache/logging/log4j/util/Constants.java#L44-L47 This is not a hard dependency — Log4j checks for the presence of the `Servlet` class reflectively and does not require it at runtime. You can find more details about this behavior in the documentation for [`log4j2.isWebapp`](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.isWebapp). If you’ve found a different kind of reference to `javax.*` packages that breaks Jakarta EE 9 compatibility, I’d appreciate a pointer to the exact code or context. GitHub link: https://github.com/apache/logging-log4j2/discussions/3682#discussioncomment-13249838 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? [logging-log4j2]
GitHub user ppkarwasz added a comment to the discussion: Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? There will be **no `3.0.0` release of the [Log4j API](https://logging.apache.org/log4j/2.x/manual/api.html)**. This is intentional: both Log4j Core 2 and Log4j Core 3 are designed to use the **same API**, meaning no code changes are required when upgrading to Log4j Core 3. The current release, `3.0.0-beta3`, of Log4j Core is fully compatible with Log4j API version `2.24.x`. To ensure your project always uses the correct API version for Log4j Core 3, we recommend using the [`log4j-bom`](https://logging.apache.org/log4j/3.x/components.html#log4j-bom) for dependency management. ## 📅 Log4j Core 3 Release Timeline Development on the 3.x line began back in 2018, around the same time as the upcoming Jackson 3.x. Since then, the `main` branch has been losing ground and catching up with the `2.x` branch in terms of bug fixes and new features—culminating in `3.0.0-beta3`, which brings us very close to parity. At this point, all planned 3.x features have been delivered. The remaining blocker for the official `3.0.0` release is porting over a final set of changes from `2.x`. As outlined in [my March email](https://lists.apache.org/thread/0jb0gcnddhffywcbfj7o9q3wtbgr1r35), we are currently focused on the `2.25.0` release and do not have the bandwidth to finalize work on 3.x at this time. ## 🙋 How You Can Help We welcome community contributions to help bring `3.0.0` across the finish line. Here’s how you can get involved: ### 🛠️ Port Changes from 2.x to 3.x Issue #3161 lists items that were completed in `2.x` but not yet ported to `main`. While some items (e.g., GraalVM support) are more complex, many are simple cherry-picks. Porting these will bring us closer to a final release. ### 🧪 Test the Beta Releases We've released several `3.x` betas, but user feedback has been limited. Testing these betas and reporting bugs—or even confirming smooth upgrades—would be incredibly valuable. We expect to publish at least one more beta before finalizing `3.0.0`. Your help could significantly accelerate the release. Thanks for being part of the Log4j community! GitHub link: https://github.com/apache/logging-log4j2/discussions/3682#discussioncomment-13245083 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? [logging-log4j2]
GitHub user garydgregory added a comment to the discussion: Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? And welcome to the pain and confusing we are forcing on our users with this confusing version policy 😞 GitHub link: https://github.com/apache/logging-log4j2/discussions/3682#discussioncomment-13245251 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? [logging-log4j2]
GitHub user jluehe added a comment to the discussion: Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? @ppkarwasz, we are looking for a Jakarta EE9 compatible version of `org.apache.logging.log4j:log4j-api`. We found that version `2.24.3` is not Jakarta EE9 compatible (as it contains references to `javax` classes), whereas version `3.0.0-beta2` is. That's why we were hoping for a proper `3.0.0` release ... GitHub link: https://github.com/apache/logging-log4j2/discussions/3682#discussioncomment-13245699 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? [logging-log4j2]
GitHub user jluehe added a comment to the discussion: Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? Thanks for your response, @ppkarwasz! Yes, the `javax` reference in `Constants.java` is "benign". The problematic reference is here: https://github.com/apache/logging-log4j2/blob/rel/2.24.3/log4j-api/src/main/java/org/apache/logging/log4j/util/Base64Util.java#L45 https://github.com/user-attachments/assets/fa75428b-3911-463b-965b-71e157306225"; /> It is not a compile dependency, but the resulting CNFE in a EE9 environment would impact functionality. GitHub link: https://github.com/apache/logging-log4j2/discussions/3682#discussioncomment-13254432 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? [logging-log4j2]
GitHub user ppkarwasz added a comment to the discussion: Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? Great catch! :100: That’s some legacy code we originally included to support Java 7. Since version `2.13.0`, our baseline has been Java 8, so we can now safely use `java.util.Base64` directly. Would you be open to submitting a PR against the `2.x` branch to help us clean this up? We're currently tied up preparing the `2.25.0` release, so your contribution would be a big help in tackling this bit of technical debt sooner. GitHub link: https://github.com/apache/logging-log4j2/discussions/3682#discussioncomment-13254717 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? [logging-log4j2]
GitHub user jluehe added a comment to the discussion: Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? Created https://github.com/apache/logging-log4j2/issues/3686 GitHub link: https://github.com/apache/logging-log4j2/discussions/3682#discussioncomment-13255364 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? [logging-log4j2]
GitHub user jluehe added a comment to the discussion: Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? Yes, @ppkarwasz, I'd be more than happy to contribute a PR against the `2.x` branch, in time for the `2.25.0` release! Please stay tuned! GitHub link: https://github.com/apache/logging-log4j2/discussions/3682#discussioncomment-13254753 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? [logging-log4j2]
GitHub user jluehe added a comment to the discussion: Timeline for org.apache.logging.log4j:log4j-api:3.0.0 release? @ppkarwasz, for your review: https://github.com/apache/logging-log4j2/pull/3687 GitHub link: https://github.com/apache/logging-log4j2/discussions/3682#discussioncomment-13255405 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] Attribute 'additivity' is not allowed to appear in element 'Logger' [logging-log4j2]
GitHub user ppkarwasz added a comment to the discussion: Attribute 'additivity' is not allowed to appear in element 'Logger' Hi @jorge683, Yes, this is indeed a bug — tracked here: apache/logging-log4j-tools#135 — in the [Log4j Docgen tool](https://logging.apache.org/log4j/tools/log4j-docgen.html), which we use to generate the XML Schema from source code. It's important to note that Log4j configuration files are inherently **schema-less** by design. Here’s why: * **Extensibility via Plugins**: Log4j Core is highly extensible — all components are implemented as [Log4j Plugins](https://logging.apache.org/log4j/2.x/manual/plugins.html). This means users can define custom plugins that the official schema won’t recognize. The published schema only includes plugins maintained by the Apache Logging Services project. * **Conditional Configuration with Arbiters**: Log4j supports a feature called [arbiters](https://logging.apache.org/log4j/2.x/manual/configuration.html#arbiters), which allows XML elements to be conditionally included at runtime. Because arbiters can introduce arbitrary structure, we’ve chosen to exclude them from the schema entirely — they simply can’t be reliably validated. * **Property Substitution in Attributes**: XML attributes in Log4j configurations always accept [property substitution expressions](https://logging.apache.org/log4j/2.x/manual/configuration.html#property-substitution), which are evaluated at configuration time. Technically, this means all attributes must be treated as strings, which limits the benefits of schema-based validation or IDE auto-completion. A user proposed using XML union types as a workaround (see [apache/logging-log4j-tools#136](https://github.com/apache/logging-log4j-tools/issues/136)), but this hasn’t yet been implemented. Because of these limitations, XML validation errors in Log4j configuration files should be taken with a grain of salt — your configuration may be perfectly valid and still trigger schema validation errors. Conversely, a configuration that passes validation might still fail at runtime if the required [Log4j Core component JARs](https://logging.apache.org/log4j/2.x/components.html) are missing. In the long term, we’re considering simplifying the schema generation process to allow users to generate a tailored XML Schema based on the specific Log4j libraries available at runtime. This would improve both the accuracy and usefulness of schema validation in real-world setups. Unfortunately, we currently don't have the bandwidth to implement this, but community contributions to improve Log4j Docgen are always welcome! GitHub link: https://github.com/apache/logging-log4j2/discussions/3696#discussioncomment-13308231 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options [logging-log4j2]
GitHub user ratoaq2 edited a discussion: java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options Hi all, I have a java 21 maven project which uses eclipse compiler org.codehaus.plexus:plexus-compiler-eclipse:2.15.0 and has a log4j plugin using a Log4j2Plugins.dat file and configured the compiler with: ``` org.apache.maven.plugins maven-compiler-plugin generate-log4j-plugin-descriptor compile process-classes only org.apache.logging.log4j log4j-core org.apache.logging.log4j.core.config.plugins.processor.PluginProcessor ``` After upgrading from 2.24.3 to 2.25.0 now my compilation is failing with: ``` 19:43:54 [INFO] --- compiler:3.14.0:compile (default-compile) @ common --- 19:43:55 [INFO] Recompiling the module because of changed source code. 19:43:55 [INFO] Compiling with eclipse [debug deprecation parameters target 21] to target/classes 19:43:55 [INFO] - 19:43:55 [ERROR] COMPILATION ERROR : 19:43:55 [INFO] - 19:43:55 [ERROR] /redacted//redacted/src/main/redacted/Redacted.java: Internal compiler error: java.lang.Exception: java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options. 19:43:55 The generation of GraalVM reflection metadata for your Log4j Plugins will be disabled. The generation of GraalVM reflection metadata for your Log4j Plugins will be disabled. 19:43:55 [ERROR] Unknown source: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options. 19:43:55 The generation of GraalVM reflection metadata for your Log4j Plugins will be disabled. 19:43:55 [INFO] 2 errors ``` Is anyone facing similar issue? I tried to specify the graal processor with its arguments, but that doesn't work either. GitHub link: https://github.com/apache/logging-log4j2/discussions/3755 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options [logging-log4j2]
GitHub user kwakeroni added a comment to the discussion: java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options I have the same issue. The release notes say "the processor will fail the build if the required log4j.graalvm.groupId and log4j.graalvm.artifactId parameters are not provided", but according to this page: https://logging.apache.org/log4j/2.x/manual/plugins.html#plugin-registry the GraalVM stuff is optional. I don't see an option to turn it off, though. GitHub link: https://github.com/apache/logging-log4j2/discussions/3755#discussioncomment-13505114 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options [logging-log4j2]
GitHub user ratoaq2 edited a discussion: java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options Hi all, I have a java 21 maven project which uses eclipse compiler org.codehaus.plexus:plexus-compiler-eclipse:2.15.0 and has a log4j plugin using a Log4j2Plugins.dat file and configured the compiler with: ``` org.apache.maven.plugins maven-compiler-plugin generate-log4j-plugin-descriptor compile process-classes only org.apache.logging.log4j log4j-core org.apache.logging.log4j.core.config.plugins.processor.PluginProcessor ``` After upgrading from 2.24.3 to 2.25.0 now my compilation is failing with: ``` 19:43:54 [INFO] --- compiler:3.14.0:compile (default-compile) @ common --- 19:43:55 [INFO] Recompiling the module because of changed source code. 19:43:55 [INFO] Compiling with eclipse [debug deprecation parameters target 21] to target/classes 19:43:55 [INFO] - 19:43:55 [ERROR] COMPILATION ERROR : 19:43:55 [INFO] - 19:43:55 [ERROR] /redacted//redacted/src/main/redacted/Redacted.java: Internal compiler error: java.lang.Exception: java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options. 19:43:55 The generation of GraalVM reflection metadata for your Log4j Plugins will be disabled. The generation of GraalVM reflection metadata for your Log4j Plugins will be disabled. 19:43:55 [ERROR] Unknown source: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options. 19:43:55 The generation of GraalVM reflection metadata for your Log4j Plugins will be disabled. 19:43:55 [INFO] 2 errors ``` Is anyone facing similar issue? I tried to specify the graal processor with its arguments, but that doesn't work either. GitHub link: https://github.com/apache/logging-log4j2/discussions/3755 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options [logging-log4j2]
GitHub user THausherr added a comment to the discussion: java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options Same for me with Apache PDFBox. What I noticed is that it works when building the subproject, but not when building the whole project which includes the subproject. GitHub link: https://github.com/apache/logging-log4j2/discussions/3755#discussioncomment-13510156 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options [logging-log4j2]
GitHub user ftreede added a comment to the discussion: java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options It is automatically registered via META-INF services. So the only way to turn it off is to turn off all annotation processing. It would be better if you'd have to explicitly enable it, I don't think it needs to be in the services if you specify it explicitly. We will rollback and hold off on 2.25 until this is fixed. GitHub link: https://github.com/apache/logging-log4j2/discussions/3755#discussioncomment-13509519 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options [logging-log4j2]
GitHub user kwakeroni added a comment to the discussion: java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options I agree. I have no annotation processors configured in my pom, all running out-of-the-box (like Lombok), and now I would need add about 20 lines just to turn of a feature because I'm using a custom appender (internal to the project) in my tests... GitHub link: https://github.com/apache/logging-log4j2/discussions/3755#discussioncomment-13519755 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options [logging-log4j2]
GitHub user ppkarwasz added a comment to the discussion: java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options Nice catch! :100: Somehow `only` ended up in my example, which disables the compilation of classes. I edited the answer to fix it. GitHub link: https://github.com/apache/logging-log4j2/discussions/3755#discussioncomment-13512543 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options [logging-log4j2]
GitHub user ppkarwasz added a comment to the discussion: java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options @THausherr, I couldn't reproduce your problems with PDFBox. I submitted my changes as apache/pdfbox#207. GitHub link: https://github.com/apache/logging-log4j2/discussions/3755#discussioncomment-13512863 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options [logging-log4j2]
GitHub user ratoaq2 added a comment to the discussion:
java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor
is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId`
options
the proc none didn't seem to work for me...
It seems I got it working with:
```xml
org.apache.logging.log4j
log4j-core
${log4j2.version}
```
GitHub link:
https://github.com/apache/logging-log4j2/discussions/3755#discussioncomment-13512931
This is an automatically sent email for dev@logging.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options [logging-log4j2]
GitHub user ratoaq2 edited a comment on the discussion:
java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor
is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId`
options
It seems I got it working with proc none plus empty annotation processors:
```xml
org.apache.logging.log4j
log4j-core
${log4j2.version}
```
GitHub link:
https://github.com/apache/logging-log4j2/discussions/3755#discussioncomment-13512931
This is an automatically sent email for dev@logging.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options [logging-log4j2]
GitHub user ratoaq2 added a comment to the discussion: java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options It seems a bit cumbersome for a project that has nothing to do with Graalvm GitHub link: https://github.com/apache/logging-log4j2/discussions/3755#discussioncomment-13512957 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options [logging-log4j2]
GitHub user ppkarwasz added a comment to the discussion: java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options The warning in the release notes warning is a simplified explanation of the actual behavior. The `GraalVmProcessor` will only produce an error out when **both** of the following are true: 1. **Your code includes at least one Log4j Core Plugin** (i.e., you have a class annotated with `@Plugin`). 2. You **did not** supply the required compiler arguments: ``` -Alog4j.graalvm.groupId= -Alog4j.graalvm.artifactId= ``` I tested this locally (using `javac` in both single- and multi-module Maven setups) without any issues—no errors appeared when no `@Plugin` was present. Can you share a snippet or small test project where the issue does occur? GitHub link: https://github.com/apache/logging-log4j2/discussions/3755#discussioncomment-13511583 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options [logging-log4j2]
GitHub user ppkarwasz added a comment to the discussion: java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options Hi @kwakeroni, There’s **no dedicated flag** to turn `GraalVmProcessor` off, since you can effectively control it through standard compiler options. As @ftreede mentioned, since Java 6, `javac` has **automatically loaded** all annotation processors found on the annotation processor path (which, by default, is just the classpath). This implicit behavior has been flagged as a security concern and is now **deprecated as of Java 23** (see [this JDK 23 heads-up](https://inside.java/2024/06/18/quality-heads-up/) and the [excellent write-up here](https://javapro.io/2024/11/19/discovering-the-perfect-java-supply-chain-attack-vector-and-how-it-got-fixed/)). Keeping the spirit of the changes in JDK 23, we intentionally make `GraalVmProcessor` fail with an **`ERROR`** (instead of silently ignoring it or logging a warning) because: * It helps developers become immediately aware that a new annotation processor is active. * It forces an **explicit decision**: either configure it properly (opt-in) or disable it (opt-out). ### ✅ How to Opt-Out Depending on whether you use **other annotation processors**, you can take one of two approaches: 1. You **don’t** use other annotation processors You can simply disable all annotation processing: ```xml org.apache.maven.plugins maven-compiler-plugin none ``` 2. You **do** use other annotation processors In this case, declare them explicitly and isolate your annotation processor classpath: ```xml org.apache.maven.plugins maven-compiler-plugin org.apache.logging.log4j log4j-core 2.25.0 org.apache.logging.log4j.core.config.plugins.processor.PluginProcessor ``` This ensures that only the processors you trust and need are loaded—nothing more, nothing less. ### ✅ How to Opt-In An example on to use both `PluginProcessor` and `GraalVmProcessor` is available on the [documentation page you site](https://logging.apache.org/log4j/2.x/manual/plugins.html#plugin-registry) GitHub link: https://github.com/apache/logging-log4j2/discussions/3755#discussioncomment-13512010 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options [logging-log4j2]
GitHub user THausherr edited a comment on the discussion:
java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor
is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId`
options
I tried the last change with default-compile and now the project that follows
the problematic project claims that the previous package doesn't exist. I
looked into the repository directory, the jar files are there, but much
smaller. It turned out the class files are missing.
```
org.apache.maven.plugins
maven-compiler-plugin
default-compile
only
org.apache.logging.log4j
log4j-core
${log4j2.version}
org.apache.logging.log4j.core.config.plugins.processor.PluginProcessor
org.apache.logging.log4j.core.config.plugins.processor.GraalVmProcessor
-Alog4j.graalvm.groupId=${project.groupId}
-Alog4j.graalvm.artifactId=${project.artifactId}
```
GitHub link:
https://github.com/apache/logging-log4j2/discussions/3755#discussioncomment-13512509
This is an automatically sent email for dev@logging.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options [logging-log4j2]
GitHub user ppkarwasz edited a comment on the discussion:
java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor
is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId`
options
Hi @ratoaq2,
Thanks for the detailed error log — it's very helpful.
>From what you've shared, the issue is occurring during the `default-compile`
>Maven Compiler Plugin execution, not in the custom
>`generate-log4j-plugin-descriptor` execution you configured. Specifically:
```
[INFO] --- compiler:3.14.0:compile (default-compile) @ common ---
[INFO] Compiling with eclipse [...] to target/classes
[ERROR] Internal compiler error: java.lang.IllegalArgumentException:
The `GraalVmProcessor` annotation processor is missing the required
`log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options.
```
If you want to use a separate execution for annotation processing, you need to
disable annotation processing in `default-compile`:
```xml
default-compile
none
```
If, on the other hand, you want to perform both compilation and annotation
processing (Log4j plugin descriptor + GraalVM metadata) **in a single Maven
execution**, you can fully configure the `default-compile` phase like this:
```xml
org.apache.maven.plugins
maven-compiler-plugin
3.14.0
org.codehaus.plexus
plexus-compiler-eclipse
2.15.0
eclipse
21
none
default-compile
org.apache.logging.log4j
log4j-core
2.25.0
org.apache.logging.log4j.core.config.plugins.processor.PluginProcessor
org.apache.logging.log4j.core.config.plugins.processor.GraalVmProcessor
-Alog4j.graalvm.groupId=${project.groupId}
-Alog4j.graalvm.artifactId=${project.artifactId}
```
I hope that helps solving your problem.
GitHub link:
https://github.com/apache/logging-log4j2/discussions/3755#discussioncomment-13512223
This is an automatically sent email for dev@logging.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
