Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
2.17.2
-
None
-
None
-
Windows 10
Windows Server 2019
Description
We are using plugins in our config, e.g.:
"configuration": { "name": "MyAppLog4JConfig", "packages": "de.mycompany.myapp.adapter.log4j.plugin", "properties": { ... "appenders": { ... "MyAppConsole": { "name": "MyApp-Console-Appender", "PatternLayout": { "pattern": "${sysPatternlayout}", "charset": "UTF-8" }
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:
LoggerContext log4j2LoggerContext = (org.apache.logging.log4j.core.LoggerContext) org.apache.logging.log4j.LogManager.getContext(true);
While trying to extract the path to our custom plugins, the PluginManager lands here: org.apache.logging.log4j.core.config.plugins.util.ResolverUtil#extractPath
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();
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". This would solve our problem with blanks but as stated in the comments, a solution that encodes the path would also take other cases of special characters into account.
So this solutions with encoding works for us too (tested with blanks in path only).
String encodedPath = URLEncoder.encode(urlPath, StandardCharsets.UTF_8.name()); final String cleanPath = new URI(encodedPath).getPath();
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 the encoding 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.
We are using the log4j-bridge at the moment, maybe this issue only shows up when using this besides log4j2 core and api