logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Heisey <apa...@elyograg.org>
Subject Re: Odd problem starting program with log4j2 on Windows
Date Thu, 05 Jul 2018 20:59:56 GMT
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:


gets translated into this:


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:


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

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):



To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

View raw message