So that is some weirdness with Java itself, and only on Windows. Ralph
> On Jul 5, 2018, at 7:34 PM, Remko Popma <remko.po...@gmail.com> wrote: > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
