logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: Odd problem starting program with log4j2 on Windows
Date Fri, 06 Jul 2018 18:26:19 GMT
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 <apache@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-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message