Shawn, I think the safest option is simply to remove the “file:” prefix since you found that works with log4j 2 on all operating systems.
Remko- (Shameless plug) Every java main() method deserves http://picocli.info > On Jul 7, 2018, at 3:26, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > Here is the entirety of the logic for Log4j 1 > > try { > url = new URL(configurationOptionStr); > } catch (MalformedURLException ex) { > // so, resource is not a URL: > // attempt to get the resource from the class path > url = Loader.getResource(configurationOptionStr); > } > The main difference I see is that Log4j 2 tries to create a URI and only > tries to create a URL if creating the URI throws an exception. > > I’m all for switching to NIO2 if it provides an easier way to find the file > from all the various places it could be. > > > Ralph > > > > > >> On Jul 6, 2018, at 10:50 AM, Shawn Heisey <apa...@elyograg.org> wrote: >> >> On 7/5/2018 8:34 PM, Remko Popma 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). >> >> Thanks to everyone who has replied, the discussion is valuable to me. >> >> If I add //, it works with absolute paths on log4j2 when running on >> Windows. I haven't checked Linux, but I suspect it would work there too. >> >> But the URI without // works on Linux in log4j2. I haven't tested, but >> I think that I would be able to use a relative path on Linux with the >> "file:" prefix. >> >> The file: URI without // works on both Linux AND Windows in log4j 1.x. >> I can use relative paths with either OS when using log4j 1.x. Something >> has changed from log4j 1.x to 2.x, something that works without problems >> on Linux but breaks on Windows. I think it's been well demonstrated >> that the problem is in Java, not log4j. >> >> For fixing the problem in Solr on Windows, I see two possibilities: >> >> One fix (which I know works) is to abandon the file: prefix entirely. >> In the Solr startup script, the location is an absolute path. But I do >> have some worries that this might break in a future version. In log4j >> 1.x the "file:" prefix appears to be mandatory -- if I remove it from >> the log4j.configuration system property, my logging configuration isn't >> found. With log4j 2.x, the system property is different -- >> log4j.configurationFile instead of log4j.configuration ... which >> suggests that URI syntax won't be required. >> >> The other fix is to add slashes after file: ... but I'm not sure whether >> it should be two slashes or three slashes. Experiments with >> Path#toUri() suggest that three slashes might be the preferred canonical >> form, but I'd like to know for sure. Two slashes does appear to work >> with log4j. >> >> Tangent: Has there been any desire in the project to abandon the File >> object and switch to NIO2? Lucene made that plunge a while back. I've >> heard that it's a much better API. >> >> Experiments with 'new URI(string)' seem to indicate that log4j (both 1.x >> and 2.x) accepts URI variations that are not allowed by the URI object. >> A prefix of "file://" with a Windows path isn't allowed -- it requires >> "file:///" to work. Because the Windows command shell provides paths >> with backlashes, it would be difficult to specify a completely valid URI >> -- backslashes do not appear to be allowed in strict syntax. >> >> 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
