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

Reply via email to