I found that the problem can be reproduced with this: new File(“file:C:\\temp\\some.file”).toURI()
If you print the above it shows: file:/C:/my/current/directory/file:C:/temp/some.file So, the configuration should not prefix the path with “file:”, but with “file:/“ (slash after the colon). (Shameless plug) Every java main() method deserves http://picocli.info > On Jul 6, 2018, at 10:52, Gary Gregory <garydgreg...@gmail.com> wrote: > > Can't URL contain commas? > > Gary > >> On Thu, Jul 5, 2018, 18:11 Ralph Goers <ralph.go...@dslextreme.com> wrote: >> >> Here is what Log4j does: >> >> If the property is specified first see if it contains any commas, if so >> then there will be multiple configuration files, which essentially does >> what follows for each file. If not then try to convert it to a URI using >> the following code: >> >> public static URI toURI(final String path) { >> try { >> // Resolves absolute URI >> return new URI(path); >> } catch (final URISyntaxException e) { >> // A file path or a Apache Commons VFS URL might contain blanks. >> // A file path may start with a driver letter >> try { >> final URL url = new URL(path); >> return new URI(url.getProtocol(), url.getHost(), >> url.getPath(), null); >> } catch (MalformedURLException | URISyntaxException nestedEx) { >> return new File(path).toURI(); >> } >> } >> } >> >> The URI is then converted to a ConfigurationSource using: >> public static ConfigurationSource fromUri(final URI configLocation) { >> final File configFile = FileUtils.fileFromUri(configLocation); >> if (configFile != null && configFile.exists() && configFile.canRead()) >> { >> try { >> return new ConfigurationSource(new >> FileInputStream(configFile), configFile); >> } catch (final FileNotFoundException ex) { >> ConfigurationFactory.LOGGER.error("Cannot locate file {}", >> configLocation.getPath(), ex); >> } >> } >> if (ConfigurationFactory.isClassLoaderUri(configLocation)) { >> final ClassLoader loader = >> LoaderUtil.getThreadContextClassLoader(); >> final String path = >> ConfigurationFactory.extractClassLoaderUriPath(configLocation); >> final ConfigurationSource source = fromResource(path, loader); >> if (source != null) { >> return source; >> } >> } >> if (!configLocation.isAbsolute()) { // LOG4J2-704 avoid confusing >> error message thrown by uri.toURL() >> ConfigurationFactory.LOGGER.error("File not found in file system >> or classpath: {}", configLocation.toString()); >> return null; >> } >> try { >> return new >> ConfigurationSource(configLocation.toURL().openStream(), >> configLocation.toURL()); >> } catch (final MalformedURLException ex) { >> ConfigurationFactory.LOGGER.error("Invalid URL {}", >> configLocation.toString(), ex); >> } catch (final Exception ex) { >> ConfigurationFactory.LOGGER.error("Unable to access {}", >> configLocation.toString(), ex); >> } >> return null; >> } >> I should point out that the stack trace log you are seeing is from the >> above code failing. If any of the above doesn’t work we then try to create >> a ConfigurationSource using the following code where config is the value of >> the property and loader is the ThreadContextClassLoader. So even with the >> error that is shown it is still possible that the file might be found. >> >> protected ConfigurationSource getInputFromString(final String config, >> final ClassLoader loader) { >> try { >> final URL url = new URL(config); >> return new ConfigurationSource(url.openStream(), >> FileUtils.fileFromUri(url.toURI())); >> } catch (final Exception ex) { >> final ConfigurationSource source = >> ConfigurationSource.fromResource(config, loader); >> if (source == null) { >> try { >> final File file = new File(config); >> return new ConfigurationSource(new FileInputStream(file), >> file); >> } catch (final FileNotFoundException fnfe) { >> // Ignore the exception >> LOGGER.catching(Level.DEBUG, fnfe); >> } >> } >> return source; >> } >> } >> ConfigurationSource.fromResource() tries to locate the resource using >> ClassLoader.getResource() and then constructs a ConfgurationSource if it >> can find it. And if all else fails we just pass the string to the File >> constructor and hope for the best. >> As you can see we aren’t really manipulating the input string that was >> provided to us, but we are trying any way we can to convert it into some >> sort of file we can access. If you see something missing in this logic >> please let us know. >> >> Ralph >> >> >> >> >> >>> On Jul 5, 2018, at 1:59 PM, Shawn Heisey <apa...@elyograg.org> wrote: >>> >>> On 7/5/2018 11:38 AM, Ralph Goers wrote: >>>> I have updated the issue you referenced. From what I can tell this is >> not an issue in Log4j. It is an issue with the way file urls work. >>> >>> Thanks for your attention. >>> >>> The startup script included with Solr versions before 7.4 (using log4j >>> 1.2.x) also did not have // in the file: URI for the log4j.properties >>> file, and it works on both Linux and Windows. >>> >>> Something else I found in the RFC you linked: >>> >>> The syntax given in Section 2 makes the entire authority component, >>> including the double slashes "//", optional. >>> >>> Reading section 2, I didn't actually see that stated. Maybe it's >>> something clarified by one of the other referenced RFCs. But if we take >>> that statement at face value, it seems to be saying that a URI without >>> // should work. It *does* work on Linux. On Windows, this: >>> >>> file:C:\path\to\stuff\log4j2.xml >>> >>> gets translated into this: >>> >>> file:/$CWD/file:C:/path/to/stuff/log4j2.xml >>> >>> Where $CWD is the current working directory. Even the "extra" URI added >>> as a prefix doesn't have the // in it. If instead we use the following, >>> it works as expected: >>> >>> file://C:\path\to\stuff\log4j2.xml >>> >>> If you're sure that there's nothing in log4j code that would result in >>> the strange location, I'd be willing to accept that this problem is >>> caused by Java or the OS and not log4j. The fact that this doesn't >>> happen on Linux is even more reason to believe that. I don't know how >>> likely it is that log4j contains code that behaves differently based on >>> detected OS ... but I strongly believe that you'd want to avoid that if >>> possible. >>> >>> I believe that we can safely add // to Solr's command script to solve >>> this issue for our users, because the value should always be a full >>> absolute path. >>> >>> But I would like to pursue the remaining question: When the RFC is >>> fully and correctly evaluated, is a "file:" URI without "//" considered >>> valid? If not, then that ends the discussion. If it is considered >>> valid, then there's another question: Is it Java, log4j, or Windows that >>> is causing the problem we've seen? >>> >>> Another question: What is the stance of the project on whether non-URI >>> syntax for the log4j.configurationFile system property will be supported >>> long-term? I can remember running into a problem with logging >>> configuration in the past (I *think* it was log4j 1.x, but it MIGHT have >>> been java.util.logging) where the configuration wasn't found until I >>> added "file:" to turn it into a URI. I did not use // in the URI. This >>> is a line from the init script I wrote for Solr 4.x versions (when Solr >>> did not include a startup script): >>> >>> LOG_OPTS="-Dlog4j.configuration=file:etc/log4j.properties" >>> >>> Thanks, >>> Shawn >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org >>> For additional commands, e-mail: log4j-user-h...@logging.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
