[GitHub] [logging-log4j-audit] dependabot[bot] opened a new pull request, #26: Bump postgresql from 42.2.0 to 42.4.1
dependabot[bot] opened a new pull request, #26: URL: https://github.com/apache/logging-log4j-audit/pull/26 Bumps [postgresql](https://github.com/pgjdbc/pgjdbc) from 42.2.0 to 42.4.1. Release notes Sourced from https://github.com/pgjdbc/pgjdbc/releases;>postgresql's releases. 42.4.0 What's Changed Enhancement: Made TimestampUtils.utcTz static and renamed to UTC_TIMEZONE by https://github.com/svendiedrichsen;>@svendiedrichsen in https://github-redirect.dependabot.com/pgjdbc/pgjdbc/pull/2519;>pgjdbc/pgjdbc#2519 fix: return correct base type for domain from getUDTs (https://github-redirect.dependabot.com/pgjdbc/pgjdbc/issues/2520;>#2520) by https://github.com/alurie;>@alurie in https://github-redirect.dependabot.com/pgjdbc/pgjdbc/pull/2522;>pgjdbc/pgjdbc#2522 fix: support queries with up to 65535 (inclusive) parameters by https://github.com/vlsi;>@vlsi in https://github-redirect.dependabot.com/pgjdbc/pgjdbc/pull/2525;>pgjdbc/pgjdbc#2525 chore: use META-INF/licenses/$group/$artifact-$version/... folder for licenses by https://github.com/vlsi;>@vlsi in https://github-redirect.dependabot.com/pgjdbc/pgjdbc/pull/2531;>pgjdbc/pgjdbc#2531 fix: added GROUP_STARTUP_PARAMETERS boolean property to determine whether or not to group startup parameters in a transaction or not fixes Issue 2423 pgbouncer cannot deal with transactions in statement pooling mode by https://github.com/davecramer;>@davecramer in https://github-redirect.dependabot.com/pgjdbc/pgjdbc/pull/2425;>pgjdbc/pgjdbc#2425 chore: Make the readme version agnostic by https://github.com/jorsol;>@jorsol in https://github-redirect.dependabot.com/pgjdbc/pgjdbc/pull/2540;>pgjdbc/pgjdbc#2540 Release notes 42.4.0 by https://github.com/davecramer;>@davecramer in https://github-redirect.dependabot.com/pgjdbc/pgjdbc/pull/2541;>pgjdbc/pgjdbc#2541 New Contributors https://github.com/svendiedrichsen;>@svendiedrichsen made their first contribution in https://github-redirect.dependabot.com/pgjdbc/pgjdbc/pull/2519;>pgjdbc/pgjdbc#2519 Full Changelog: https://github.com/pgjdbc/pgjdbc/compare/REL42.3.6...REL42.4.0;>https://github.com/pgjdbc/pgjdbc/compare/REL42.3.6...REL42.4.0 Changelog Sourced from https://github.com/pgjdbc/pgjdbc/blob/master/CHANGELOG.md;>postgresql's changelog. Changelog Notable changes since version 42.0.0, read the complete https://jdbc.postgresql.org/documentation/changelog.html;>History of Changes. The format is based on http://keepachangelog.com/en/1.0.0/;>Keep a Changelog. [Unreleased] Changed Added Fixed [42.4.1] (2022-08-01 16:24:20 -0400) Security fix: CVE-2022-31197 Fixes SQL generated in PgResultSet.refresh() to escape column identifiers so as to prevent SQL injection. Previously, the column names for both key and data columns in the table were copied as-is into the generated SQL. This allowed a malicious table with column names that include statement terminator to be parsed and executed as multiple separate commands. Also adds a new test class ResultSetRefreshTest to verify this change. Reported by https://github.com/kato-sho;>Sho Kato Changed chore: skip publishing pgjdbc-osgi-test to Central chore: bump Gradle to 7.5 test: update JUnit to 5.8.2 Added chore: added Gradle Wrapper Validation for verifying gradle-wrapper.jar chore: added permissions: contents: read for GitHub Actions to avoid unintentional modifications by the CI chore: support building pgjdbc with Java 17 Fixed [42.4.0] (2022-06-09 08:14:02 -0400) Changed fix: added GROUP_STARTUP_PARAMETERS boolean property to determine whether or not to group startup parameters in a transaction (default=false like 42.2.x) fixes [Issue https://github-redirect.dependabot.com/pgjdbc/pgjdbc/issues/2425;>#2425](https://github-redirect.dependabot.com/pgjdbc/pgjdbc/issues/2497;>pgjdbc/pgjdbc#2497) pgbouncer cannot deal with transactions in statement pooling mode [PR https://github-redirect.dependabot.com/pgjdbc/pgjdbc/issues/2425;>#2425](https://github-redirect.dependabot.com/pgjdbc/pgjdbc/pull/2425;>pgjdbc/pgjdbc#2425) Fixed fix: queries with up to 65535 (inclusive) parameters are supported now (previous limit was 32767) [PR https://github-redirect.dependabot.com/pgjdbc/pgjdbc/issues/2525;>#2525](https://github-redirect.dependabot.com/pgjdbc/pgjdbc/pull/2525;>pgjdbc/pgjdbc#2525), [Issue https://github-redirect.dependabot.com/pgjdbc/pgjdbc/issues/1311;>#1311](https://github-redirect.dependabot.com/pgjdbc/pgjdbc/issues/1311;>pgjdbc/pgjdbc#1311) fix: workaround JarIndex parsing issue by using groupId/artifactId-version directory namings. Regression since 42.2.13. [PR https://github-redirect.dependabot.com/pgjdbc/pgjdbc/issues/2531;>#2531](https://github-redirect.dependabot.com/pgjdbc/pgjdbc/pull/2531;>pgjdbc/pgjdbc#2531), [issue
[jira] [Commented] (LOG4J2-3568) ResolverUtil fails to extractPath for custom plugins in jar, if there are blanks in the path
[
https://issues.apache.org/jira/browse/LOG4J2-3568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575940#comment-17575940
]
Ralph Goers commented on LOG4J2-3568:
-
I was going to say the same thing. The url path should be url encoded.
> ResolverUtil fails to extractPath for custom plugins in jar, if there are
> blanks in the path
>
>
> Key: LOG4J2-3568
> URL: https://issues.apache.org/jira/browse/LOG4J2-3568
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 2.17.2
> Environment: Windows 10
> Windows Server 2019
>Reporter: Sven Seelig
>Priority: Major
>
> We are using plugins in our config, e.g.:
> {noformat}
> "configuration": {
> "name": "MyAppLog4JConfig",
> "packages": "de.mycompany.myapp.adapter.log4j.plugin",
> "properties": {
> ...
> "appenders": {
> ...
> "MyAppConsole": {
> "name": "MyApp-Console-Appender",
> "PatternLayout": {
> "pattern": "${sysPatternlayout}",
> "charset": "UTF-8"
> }
> {noformat}
> Everything works fine until the installation path of our application contains
> one or more blanks, e.g. "C:\Program Files\MyApp_13.0.1".
>
> The plugin classes and the log4j2.json are delivered within jar files
> (different jar files, same folder). The config-file itself is found and read.
> We are accessing the context in a standard way:
>
> {code:java}
> LoggerContext log4j2LoggerContext =
> (org.apache.logging.log4j.core.LoggerContext)
> org.apache.logging.log4j.LogManager.getContext(true);
> {code}
>
> While trying to extract the path to our custom plugins, the PluginManager
> lands here:
> org.apache.logging.log4j.core.config.plugins.util.ResolverUtil#extractPath
> {code:java}
> String extractPath(final URL url) throws UnsupportedEncodingException,
> URISyntaxException {
> String urlPath = url.getPath(); // same as getFile but without the Query
> portion
> [...]
> // For jar: URLs, the path part starts with "file:"
> if (urlPath.startsWith("file:")) {
> urlPath = urlPath.substring(5);
> }
> // If it was in a JAR, grab the path to the jar
> final int bangIndex = urlPath.indexOf('!');
> if (bangIndex > 0) {
> urlPath = urlPath.substring(0, bangIndex);
> }
> [...]
> final String cleanPath = new URI(urlPath).getPath(); {code}
> Problem is, if the urlPath contains blank(s), the new URI(...) call will
> throw an URISyntaxException and the plugins are not loaded.
> Simple solution would be an additional check and replacement of the blanks
> with "%20".
> {code:java}
> if(urlPath.contains(" ")){
> urlPath = urlPath.replace(" ", "%20");
> }
> final String cleanPath = new URI(urlPath).getPath(); {code}
> or
> {code:java}
> final String cleanPath = new URI(urlPath.replace(" ", "%20")).getPath();
> {code}
> We built the current release-2,x from the repo
> ([https://gitbox.apache.org/repos/asf/logging-log4j2.git]), had the same
> issue as before (2.17.2) but with this check added it works.
> As we can't run the maven build with tests (there seems to be a proxy issue
> for the MongoDB Tests), we decided not to open a pull-request. Please let us
> know, if you prefer a pull-request or if you need further information.
> (i) We are using the log4j-bridge at the moment, maybe this issue only shows
> up when using this besides log4j2 core and api (i)
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3568) ResolverUtil fails to extractPath for custom plugins in jar, if there are blanks in the path
[
https://issues.apache.org/jira/browse/LOG4J2-3568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575800#comment-17575800
]
Gary D. Gregory commented on LOG4J2-3568:
-
A special case for space is not good enough because it ignores other characters
that need to be URL encoded :-(
> ResolverUtil fails to extractPath for custom plugins in jar, if there are
> blanks in the path
>
>
> Key: LOG4J2-3568
> URL: https://issues.apache.org/jira/browse/LOG4J2-3568
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 2.17.2
> Environment: Windows 10
> Windows Server 2019
>Reporter: Sven Seelig
>Priority: Major
>
> We are using plugins in our config, e.g.:
> {noformat}
> "configuration": {
> "name": "MyAppLog4JConfig",
> "packages": "de.mycompany.myapp.adapter.log4j.plugin",
> "properties": {
> ...
> "appenders": {
> ...
> "MyAppConsole": {
> "name": "MyApp-Console-Appender",
> "PatternLayout": {
> "pattern": "${sysPatternlayout}",
> "charset": "UTF-8"
> }
> {noformat}
> Everything works fine until the installation path of our application contains
> one or more blanks, e.g. "C:\Program Files\MyApp_13.0.1".
>
> The plugin classes and the log4j2.json are delivered within jar files
> (different jar files, same folder). The config-file itself is found and read.
> We are accessing the context in a standard way:
>
> {code:java}
> LoggerContext log4j2LoggerContext =
> (org.apache.logging.log4j.core.LoggerContext)
> org.apache.logging.log4j.LogManager.getContext(true);
> {code}
>
> While trying to extract the path to our custom plugins, the PluginManager
> lands here:
> org.apache.logging.log4j.core.config.plugins.util.ResolverUtil#extractPath
> {code:java}
> String extractPath(final URL url) throws UnsupportedEncodingException,
> URISyntaxException {
> String urlPath = url.getPath(); // same as getFile but without the Query
> portion
> [...]
> // For jar: URLs, the path part starts with "file:"
> if (urlPath.startsWith("file:")) {
> urlPath = urlPath.substring(5);
> }
> // If it was in a JAR, grab the path to the jar
> final int bangIndex = urlPath.indexOf('!');
> if (bangIndex > 0) {
> urlPath = urlPath.substring(0, bangIndex);
> }
> [...]
> final String cleanPath = new URI(urlPath).getPath(); {code}
> Problem is, if the urlPath contains blank(s), the new URI(...) call will
> throw an URISyntaxException and the plugins are not loaded.
> Simple solution would be an additional check and replacement of the blanks
> with "%20".
> {code:java}
> if(urlPath.contains(" ")){
> urlPath = urlPath.replace(" ", "%20");
> }
> final String cleanPath = new URI(urlPath).getPath(); {code}
> or
> {code:java}
> final String cleanPath = new URI(urlPath.replace(" ", "%20")).getPath();
> {code}
> We built the current release-2,x from the repo
> ([https://gitbox.apache.org/repos/asf/logging-log4j2.git]), had the same
> issue as before (2.17.2) but with this check added it works.
> As we can't run the maven build with tests (there seems to be a proxy issue
> for the MongoDB Tests), we decided not to open a pull-request. Please let us
> know, if you prefer a pull-request or if you need further information.
> (i) We are using the log4j-bridge at the moment, maybe this issue only shows
> up when using this besides log4j2 core and api (i)
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (LOG4J2-3568) ResolverUtil fails to extractPath for custom plugins in jar, if there are blanks in the path
[
https://issues.apache.org/jira/browse/LOG4J2-3568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sven Seelig updated LOG4J2-3568:
Description:
We are using plugins in our config, e.g.:
{noformat}
"configuration": {
"name": "MyAppLog4JConfig",
"packages": "de.mycompany.myapp.adapter.log4j.plugin",
"properties": {
...
"appenders": {
...
"MyAppConsole": {
"name": "MyApp-Console-Appender",
"PatternLayout": {
"pattern": "${sysPatternlayout}",
"charset": "UTF-8"
}
{noformat}
Everything works fine until the installation path of our application contains
one or more blanks, e.g. "C:\Program Files\MyApp_13.0.1".
The plugin classes and the log4j2.json are delivered within jar files
(different jar files, same folder). The config-file itself is found and read.
We are accessing the context in a standard way:
{code:java}
LoggerContext log4j2LoggerContext =
(org.apache.logging.log4j.core.LoggerContext)
org.apache.logging.log4j.LogManager.getContext(true);
{code}
While trying to extract the path to our custom plugins, the PluginManager lands
here:
org.apache.logging.log4j.core.config.plugins.util.ResolverUtil#extractPath
{code:java}
String extractPath(final URL url) throws UnsupportedEncodingException,
URISyntaxException {
String urlPath = url.getPath(); // same as getFile but without the Query
portion
[...]
// For jar: URLs, the path part starts with "file:"
if (urlPath.startsWith("file:")) {
urlPath = urlPath.substring(5);
}
// If it was in a JAR, grab the path to the jar
final int bangIndex = urlPath.indexOf('!');
if (bangIndex > 0) {
urlPath = urlPath.substring(0, bangIndex);
}
[...]
final String cleanPath = new URI(urlPath).getPath(); {code}
Problem is, if the urlPath contains blank(s), the new URI(...) call will throw
an URISyntaxException and the plugins are not loaded.
Simple solution would be an additional check and replacement of the blanks with
"%20".
{code:java}
if(urlPath.contains(" ")){
urlPath = urlPath.replace(" ", "%20");
}
final String cleanPath = new URI(urlPath).getPath(); {code}
or
{code:java}
final String cleanPath = new URI(urlPath.replace(" ", "%20")).getPath(); {code}
We built the current release-2,x from the repo
([https://gitbox.apache.org/repos/asf/logging-log4j2.git]), had the same issue
as before (2.17.2) but with this check added it works.
As we can't run the maven build with tests (there seems to be a proxy issue for
the MongoDB Tests), we decided not to open a pull-request. Please let us know,
if you prefer a pull-request or if you need further information.
(i) We are using the log4j-bridge at the moment, maybe this issue only shows up
when using this besides log4j2 core and api (i)
was:
We are using plugins in our config, e.g.:
{noformat}
"configuration": {
"name": "MyAppLog4JConfig",
"packages": "de.mycompany.myapp.adapter.log4j.plugin",
"properties": {
...
"appenders": {
...
"MyAppConsole": {
"name": "MyApp-Console-Appender",
"PatternLayout": {
"pattern": "${sysPatternlayout}",
"charset": "UTF-8"
}
{noformat}
Everything works fine until the installation path of our application contains
one or more blanks, e.g. "C:\Program Files\MyApp_13.0.1".
The plugin classes and the log4j2.json are delivered within jar files
(different jar files, same folder). The config-file itself is found and read.
We are accessing the context in a standard way:
{code:java}
LoggerContext log4j2LoggerContext =
(org.apache.logging.log4j.core.LoggerContext)
org.apache.logging.log4j.LogManager.getContext(true);
{code}
While trying to extract the path to our custom plugins, the PluginManager lands
here:
org.apache.logging.log4j.core.config.plugins.util.ResolverUtil#extractPath
{code:java}
String extractPath(final URL url) throws UnsupportedEncodingException,
URISyntaxException {
String urlPath = url.getPath(); // same as getFile but without the Query
portion
[...]
// For jar: URLs, the path part starts with "file:"
if (urlPath.startsWith("file:")) {
urlPath = urlPath.substring(5);
}
// If it was in a JAR, grab the path to the jar
final int bangIndex = urlPath.indexOf('!');
if (bangIndex > 0) {
urlPath = urlPath.substring(0, bangIndex);
}
[...]
final String cleanPath = new URI(urlPath).getPath(); {code}
Problem is, if the urlPath contains blank(s), the new URI(...) call will throw
an URISyntaxException and the plugins are not loaded.
Simple solution would be an additional check and replacement of the blanks with
"%20".
{code:java}
if(urlPath.contains(" ")){
urlPath = urlPath.replace(" ", "%20");
}
final String cleanPath = new URI(urlPath).getPath(); {code}
We built the current release-2,x from the repo
([https://gitbox.apache.org/repos/asf/logging-log4j2.git]), had the same
[jira] [Updated] (LOG4J2-3568) ResolverUtil fails to extractPath for custom plugins in jar, if there are blanks in the path
[
https://issues.apache.org/jira/browse/LOG4J2-3568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sven Seelig updated LOG4J2-3568:
Description:
We are using plugins in our config, e.g.:
{noformat}
"configuration": {
"name": "MyAppLog4JConfig",
"packages": "de.mycompany.myapp.adapter.log4j.plugin",
"properties": {
...
"appenders": {
...
"MyAppConsole": {
"name": "MyApp-Console-Appender",
"PatternLayout": {
"pattern": "${sysPatternlayout}",
"charset": "UTF-8"
}
{noformat}
Everything works fine until the installation path of our application contains
one or more blanks, e.g. "C:\Program Files\MyApp_13.0.1".
The plugin classes and the log4j2.json are delivered within jar files
(different jar files, same folder). The config-file itself is found and read.
We are accessing the context in a standard way:
{code:java}
LoggerContext log4j2LoggerContext =
(org.apache.logging.log4j.core.LoggerContext)
org.apache.logging.log4j.LogManager.getContext(true);
{code}
While trying to extract the path to our custom plugins, the PluginManager lands
here:
org.apache.logging.log4j.core.config.plugins.util.ResolverUtil#extractPath
{code:java}
String extractPath(final URL url) throws UnsupportedEncodingException,
URISyntaxException {
String urlPath = url.getPath(); // same as getFile but without the Query
portion
[...]
// For jar: URLs, the path part starts with "file:"
if (urlPath.startsWith("file:")) {
urlPath = urlPath.substring(5);
}
// If it was in a JAR, grab the path to the jar
final int bangIndex = urlPath.indexOf('!');
if (bangIndex > 0) {
urlPath = urlPath.substring(0, bangIndex);
}
[...]
final String cleanPath = new URI(urlPath).getPath(); {code}
Problem is, if the urlPath contains blank(s), the new URI(...) call will throw
an URISyntaxException and the plugins are not loaded.
Simple solution would be an additional check and replacement of the blanks with
"%20".
{code:java}
if(urlPath.contains(" ")){
urlPath = urlPath.replace(" ", "%20");
}
final String cleanPath = new URI(urlPath).getPath(); {code}
We built the current release-2,x from the repo
([https://gitbox.apache.org/repos/asf/logging-log4j2.git]), had the same issue
as before (2.17.2) but with this check added it works.
As we can't run the maven build with tests (there seems to be a proxy issue for
the MongoDB Tests), we decided not to open a pull-request. Please let us know,
if you prefer a pull-request or if you need further information.
(i) We are using the log4j-bridge at the moment, maybe this issue only shows up
when using this besides log4j2 core and api (i)
was:
We are using plugins in our config, e.g.:
{noformat}
"configuration": {
"name": "DSSLog4JConfig",
"packages": "de.schufa.dss.adapter.log4j.plugin",
"properties": {
...
"appenders": {
...
"DssConsole": {
"name": "Dss-Console-Appender",
"PatternLayout": {
"pattern": "${sysPatternlayout}",
"charset": "UTF-8"
}
{noformat}
Everything works fine until the installation path of our application contains
one or more blanks, e.g. "C:\Program Files\DSS_13.0.1".
The plugin classes and the log4j2.json are delivered within jar files
(different jar files, same folder). The config-file itself is found and read.
We are accessing the context in a standard way:
{code:java}
LoggerContext log4j2LoggerContext =
(org.apache.logging.log4j.core.LoggerContext)
org.apache.logging.log4j.LogManager.getContext(true);
{code}
While trying to extract the path to our custom plugins, the PluginManager lands
here:
org.apache.logging.log4j.core.config.plugins.util.ResolverUtil#extractPath
{code:java}
String extractPath(final URL url) throws UnsupportedEncodingException,
URISyntaxException {
String urlPath = url.getPath(); // same as getFile but without the Query
portion
[...]
// For jar: URLs, the path part starts with "file:"
if (urlPath.startsWith("file:")) {
urlPath = urlPath.substring(5);
}
// If it was in a JAR, grab the path to the jar
final int bangIndex = urlPath.indexOf('!');
if (bangIndex > 0) {
urlPath = urlPath.substring(0, bangIndex);
}
[...]
final String cleanPath = new URI(urlPath).getPath(); {code}
Problem is, if the urlPath contains blank(s), the new URI(...) call will throw
an URISyntaxException and the plugins are not loaded.
Simple solution would be an additional check and replacement of the blanks with
"%20".
{code:java}
if(urlPath.contains(" ")){
urlPath = urlPath.replace(" ", "%20");
}
final String cleanPath = new URI(urlPath).getPath(); {code}
We built the current release-2,x from the repo
([https://gitbox.apache.org/repos/asf/logging-log4j2.git]), had the same issue
as before (2.17.2) but with this check added it works.
As we can't run the maven build with tests
[GitHub] [logging-log4j2] dependabot[bot] opened a new pull request, #994: Bump maven-site-plugin from 3.11.0 to 3.12.1
dependabot[bot] opened a new pull request, #994: URL: https://github.com/apache/logging-log4j2/pull/994 Bumps [maven-site-plugin](https://github.com/apache/maven-site-plugin) from 3.11.0 to 3.12.1. Commits https://github.com/apache/maven-site-plugin/commit/ecae28fb0990eb5a7fc8f2d4ffe07f348d927f4b;>ecae28f [maven-release-plugin] prepare release maven-site-plugin-3.12.1 https://github.com/apache/maven-site-plugin/commit/d98569b083ded7a5182bf6cb5814ddcbd3150267;>d98569b [MSITE-908] Upgrade Maven Reporting API to 3.1.1 https://github.com/apache/maven-site-plugin/commit/bd3376f52d0053e05c78327aad39353710702a7a;>bd3376f [MSITE-901] If precending standalone report has been run, site:jar does not r... https://github.com/apache/maven-site-plugin/commit/b99c0ef371774a414ade764f2921bdfe8918ed60;>b99c0ef [MSITE-902] Upgrade Plexus Utils to 3.4.2 https://github.com/apache/maven-site-plugin/commit/3c6ff2e285063231b7042bfe7875871c9d339830;>3c6ff2e Update CI URL https://github.com/apache/maven-site-plugin/commit/f314e9da6ba0b5611fd5dd7dcff2d9ecc36dcd61;>f314e9d [MSITE-898] Upgrade Parent to 36 https://github.com/apache/maven-site-plugin/commit/bce7458375464e58f5d2d6cff92f8dde5f45de67;>bce7458 [MSITE-897] Upgrade Plexus Archiver to 4.2.7 https://github.com/apache/maven-site-plugin/commit/3c8d426aae79c793a2a3acfddbd47a6826346382;>3c8d426 keep only release month, drop day https://github.com/apache/maven-site-plugin/commit/6604ab3b53d3f4045cc755340aeb0c4feaeaf8df;>6604ab3 also keep only Doxia versions changes https://github.com/apache/maven-site-plugin/commit/789a7a1054babde3c5b01e48bbf8abca49f5af8f;>789a7a1 lighten content: keep only meaningful values Additional commits viewable in https://github.com/apache/maven-site-plugin/compare/maven-site-plugin-3.11.0...maven-site-plugin-3.12.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 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4j2] dependabot[bot] commented on pull request #832: Bump maven-site-plugin from 3.11.0 to 3.12.0
dependabot[bot] commented on PR #832: URL: https://github.com/apache/logging-log4j2/pull/832#issuecomment-1206275383 Superseded by #994. -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4j2] dependabot[bot] closed pull request #832: Bump maven-site-plugin from 3.11.0 to 3.12.0
dependabot[bot] closed pull request #832: Bump maven-site-plugin from 3.11.0 to 3.12.0 URL: https://github.com/apache/logging-log4j2/pull/832 -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (LOG4J2-3568) ResolverUtil fails to extractPath for custom plugins in jar, if there are blanks in the path
[
https://issues.apache.org/jira/browse/LOG4J2-3568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sven Seelig updated LOG4J2-3568:
Description:
We are using plugins in our config, e.g.:
{noformat}
"configuration": {
"name": "DSSLog4JConfig",
"packages": "de.schufa.dss.adapter.log4j.plugin",
"properties": {
...
"appenders": {
...
"DssConsole": {
"name": "Dss-Console-Appender",
"PatternLayout": {
"pattern": "${sysPatternlayout}",
"charset": "UTF-8"
}
{noformat}
Everything works fine until the installation path of our application contains
one or more blanks, e.g. "C:\Program Files\DSS_13.0.1".
The plugin classes and the log4j2.json are delivered within jar files
(different jar files, same folder). The config-file itself is found and read.
We are accessing the context in a standard way:
{code:java}
LoggerContext log4j2LoggerContext =
(org.apache.logging.log4j.core.LoggerContext)
org.apache.logging.log4j.LogManager.getContext(true);
{code}
While trying to extract the path to our custom plugins, the PluginManager lands
here:
org.apache.logging.log4j.core.config.plugins.util.ResolverUtil#extractPath
{code:java}
String extractPath(final URL url) throws UnsupportedEncodingException,
URISyntaxException {
String urlPath = url.getPath(); // same as getFile but without the Query
portion
[...]
// For jar: URLs, the path part starts with "file:"
if (urlPath.startsWith("file:")) {
urlPath = urlPath.substring(5);
}
// If it was in a JAR, grab the path to the jar
final int bangIndex = urlPath.indexOf('!');
if (bangIndex > 0) {
urlPath = urlPath.substring(0, bangIndex);
}
[...]
final String cleanPath = new URI(urlPath).getPath(); {code}
Problem is, if the urlPath contains blank(s), the new URI(...) call will throw
an URISyntaxException and the plugins are not loaded.
Simple solution would be an additional check and replacement of the blanks with
"%20".
{code:java}
if(urlPath.contains(" ")){
urlPath = urlPath.replace(" ", "%20");
}
final String cleanPath = new URI(urlPath).getPath(); {code}
We built the current release-2,x from the repo
([https://gitbox.apache.org/repos/asf/logging-log4j2.git]), had the same issue
as before (2.17.2) but with this check added it works.
As we can't run the maven build with tests (there seems to be a proxy issue for
the MongoDB Tests), we decided not to open a pull-request. Please let us know,
if you prefer a pull-request or if you need further information.
(i) We are using the log4j-bridge at the moment, maybe this issue only shows up
when using this besides log4j2 core and api (i)
was:
We are using plugins in our config, e.g.:
{noformat}
"configuration": {
"name": "DSSLog4JConfig",
"packages": "de.schufa.dss.adapter.log4j.plugin",
"properties": {
...
"appenders": {
...
"DssConsole": {
"name": "Dss-Console-Appender",
"PatternLayout": {
"pattern": "${sysPatternlayout}",
"charset": "UTF-8"
}
{noformat}
Everything works fine until the installation path of our application contains
one or more blanks, e.g. "C:\Program Files\DSS_13.0.1".
The plugin classes and the log4j2.json are delivered within jar files
(different jar files, same folder). The config-file itself is found and read.
We are accessing the context in a standard way:
{code:java}
LoggerContext log4j2LoggerContext =
(org.apache.logging.log4j.core.LoggerContext)
org.apache.logging.log4j.LogManager.getContext(true);
{code}
While trying to extract the path to our custom plugins, the PluginManager lands
here:
org.apache.logging.log4j.core.config.plugins.util.ResolverUtil#extractPath
{code:java}
String extractPath(final URL url) throws UnsupportedEncodingException,
URISyntaxException {
String urlPath = url.getPath(); // same as getFile but without the Query
portion
[...]
// For jar: URLs, the path part starts with "file:"
if (urlPath.startsWith("file:")) {
urlPath = urlPath.substring(5);
}
// If it was in a JAR, grab the path to the jar
final int bangIndex = urlPath.indexOf('!');
if (bangIndex > 0) {
urlPath = urlPath.substring(0, bangIndex);
}
[...]
final String cleanPath = new URI(urlPath).getPath(); {code}
Problem is, if the urlPath contains blank(s), the new URI(...) call will throw
an URISyntaxException and the plugins are not loaded.
Simple solution would be an additional check and replacement of the blanks with
"%20".
{code:java}
if(urlPath.contains(" ")){
// System.out.println("Blank in URL detected, will fail as URI! Replacing
with '%20'");
urlPath = urlPath.replaceAll(" ", "%20");
}
final String cleanPath = new URI(urlPath).getPath(); {code}
We built the current release-2,x from the repo
([https://gitbox.apache.org/repos/asf/logging-log4j2.git]), had the same issue
as before
[jira] [Updated] (LOG4J2-3568) ResolverUtil fails to extractPath for custom plugins in jar, if there are blanks in the path
[
https://issues.apache.org/jira/browse/LOG4J2-3568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sven Seelig updated LOG4J2-3568:
Description:
We are using plugins in our config, e.g.:
{noformat}
"configuration": {
"name": "DSSLog4JConfig",
"packages": "de.schufa.dss.adapter.log4j.plugin",
"properties": {
...
"appenders": {
...
"DssConsole": {
"name": "Dss-Console-Appender",
"PatternLayout": {
"pattern": "${sysPatternlayout}",
"charset": "UTF-8"
}
{noformat}
Everything works fine until the installation path of our application contains
one or more blanks, e.g. "C:\Program Files\DSS_13.0.1".
The plugin classes and the log4j2.json are delivered within jar files
(different jar files, same folder). The config-file itself is found and read.
We are accessing the context in a standard way:
{code:java}
LoggerContext log4j2LoggerContext =
(org.apache.logging.log4j.core.LoggerContext)
org.apache.logging.log4j.LogManager.getContext(true);
{code}
While trying to extract the path to our custom plugins, the PluginManager lands
here:
org.apache.logging.log4j.core.config.plugins.util.ResolverUtil#extractPath
{code:java}
String extractPath(final URL url) throws UnsupportedEncodingException,
URISyntaxException {
String urlPath = url.getPath(); // same as getFile but without the Query
portion
[...]
// For jar: URLs, the path part starts with "file:"
if (urlPath.startsWith("file:")) {
urlPath = urlPath.substring(5);
}
// If it was in a JAR, grab the path to the jar
final int bangIndex = urlPath.indexOf('!');
if (bangIndex > 0) {
urlPath = urlPath.substring(0, bangIndex);
}
[...]
final String cleanPath = new URI(urlPath).getPath(); {code}
Problem is, if the urlPath contains blank(s), the new URI(...) call will throw
an URISyntaxException and the plugins are not loaded.
Simple solution would be an additional check and replacement of the blanks with
"%20".
{code:java}
if(urlPath.contains(" ")){
// System.out.println("Blank in URL detected, will fail as URI! Replacing
with '%20'");
urlPath = urlPath.replaceAll(" ", "%20");
}
final String cleanPath = new URI(urlPath).getPath(); {code}
We built the current release-2,x from the repo
([https://gitbox.apache.org/repos/asf/logging-log4j2.git]), had the same issue
as before (2.17.2) but with this check added it works.
As we can't run the maven build with tests (there seems to be a proxy issue for
the MongoDB Tests), we decided not to open a pull-request. Please let us know,
if you prefer a pull-request or if you need further information.
(i) We are using the log4j-bridge at the moment, maybe this issue only shows up
when using this besides log4j2 core and api (i)
was:
We are using plugins in our config, e.g.:
{noformat}
"configuration": {
"name": "DSSLog4JConfig",
"packages": "de.schufa.dss.adapter.log4j.plugin",
"properties": {
...
"appenders": {
...
"DssConsole": {
"name": "Dss-Console-Appender",
"PatternLayout": {
"pattern": "${sysPatternlayout}",
"charset": "UTF-8"
}
{noformat}
Everything works fine until the installation path of our application contains
one or more blanks, e.g. "C:\Program Files\DSS_13.0.1".
The plugin classes and the log4j2.json are delivered within jar files
(different jar files, same folder). The config-file itself is found and read.
We are accessing the context in a standard way:
{code:java}
LoggerContext log4j2LoggerContext =
(org.apache.logging.log4j.core.LoggerContext)
org.apache.logging.log4j.LogManager.getContext(true);
{code}
While trying to extract the path to our custom plugins, the PluginManager lands
here:
org.apache.logging.log4j.core.config.plugins.util.ResolverUtil#extractPath
{code:java}
String extractPath(final URL url) throws UnsupportedEncodingException,
URISyntaxException {
String urlPath = url.getPath(); // same as getFile but without the Query
portion
[...]
// For jar: URLs, the path part starts with "file:"
if (urlPath.startsWith("file:")) {
urlPath = urlPath.substring(5);
}
// If it was in a JAR, grab the path to the jar
final int bangIndex = urlPath.indexOf('!');
if (bangIndex > 0) {
urlPath = urlPath.substring(0, bangIndex);
}
[...]
final String cleanPath = new URI(urlPath).getPath(); {code}
Problem is, if the urlPath contains blank(s), the new URI(...) call will throw
an URISyntaxException and the plugins are not loaded.
Simple solution would be an additional check and replacement of the blanks with
"%20".
{code:java}
if(urlPath.contains(" ")){
// System.out.println("Blank in URL detected, will fail as URI! Replacing
with '%20'");
urlPath = urlPath.replaceAll(" ", "%20");
}
final String cleanPath = new URI(urlPath).getPath(); {code}
We built the current release-2,x from the repo
[jira] [Created] (LOG4J2-3568) ResolverUtil fails to extractPath for custom plugins in jar, if there are blanks in the path
Sven Seelig created LOG4J2-3568:
---
Summary: ResolverUtil fails to extractPath for custom plugins in
jar, if there are blanks in the path
Key: LOG4J2-3568
URL: https://issues.apache.org/jira/browse/LOG4J2-3568
Project: Log4j 2
Issue Type: Bug
Components: Configuration
Affects Versions: 2.17.2
Environment: Windows 10
Windows Server 2019
Reporter: Sven Seelig
We are using plugins in our config, e.g.:
{noformat}
"configuration": {
"name": "DSSLog4JConfig",
"packages": "de.schufa.dss.adapter.log4j.plugin",
"properties": {
...
"appenders": {
...
"DssConsole": {
"name": "Dss-Console-Appender",
"PatternLayout": {
"pattern": "${sysPatternlayout}",
"charset": "UTF-8"
}
{noformat}
Everything works fine until the installation path of our application contains
one or more blanks, e.g. "C:\Program Files\DSS_13.0.1".
The plugin classes and the log4j2.json are delivered within jar files
(different jar files, same folder). The config-file itself is found and read.
We are accessing the context in a standard way:
{code:java}
LoggerContext log4j2LoggerContext =
(org.apache.logging.log4j.core.LoggerContext)
org.apache.logging.log4j.LogManager.getContext(true);
{code}
While trying to extract the path to our custom plugins, the PluginManager lands
here:
org.apache.logging.log4j.core.config.plugins.util.ResolverUtil#extractPath
{code:java}
String extractPath(final URL url) throws UnsupportedEncodingException,
URISyntaxException {
String urlPath = url.getPath(); // same as getFile but without the Query
portion
[...]
// For jar: URLs, the path part starts with "file:"
if (urlPath.startsWith("file:")) {
urlPath = urlPath.substring(5);
}
// If it was in a JAR, grab the path to the jar
final int bangIndex = urlPath.indexOf('!');
if (bangIndex > 0) {
urlPath = urlPath.substring(0, bangIndex);
}
[...]
final String cleanPath = new URI(urlPath).getPath(); {code}
Problem is, if the urlPath contains blank(s), the new URI(...) call will throw
an URISyntaxException and the plugins are not loaded.
Simple solution would be an additional check and replacement of the blanks with
"%20".
{code:java}
if(urlPath.contains(" ")){
// System.out.println("Blank in URL detected, will fail as URI! Replacing
with '%20'");
urlPath = urlPath.replaceAll(" ", "%20");
}
final String cleanPath = new URI(urlPath).getPath(); {code}
We built the current release-2,x from the repo
([https://gitbox.apache.org/repos/asf/logging-log4j2.git]), had the same issue
as before (2.17.2) but with this check added and it works.
As we can't run the maven build with tests (there seems to be a proxy issue for
the MongoDB Tests), we decided not to open a pull-request. Please let us know,
if you prefer a pull-request or if you need further information.
(i) We are using the log4j-bridge at the moment, maybe this issue only shows up
when using this besides log4j2 core and api (i)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
