That is true, but it's the log4j bootstrapping problem.  If the user has provided a custom log4j.property file, this message will go to the wrong place (i.e. the included log4j.property file not where the user has specified). But at this phase of the startup process, before the config has been parsed, this is the best we've got. My thinking was log it here and once we have loaded the user specified log config, log it again. I also have written it to stderr, but that message might disappear (debian bug) or the user might not look there, since they might be used to looking in their user specified log location.