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
