Как интерпретировать системное свойство user.dir в commons-daemon procrun & log4j?
Я установил пакетный процесс Java, используя версию procrun, которая поставляется с tomcat 5.5.33:
Commons Daemon Service Runner version 1.0.5.0/Win32 (Jan 5 2011)
Copyright (c) 2000-2011 The Apache Software Foundation.
В установке я указываю (среди других опций JVM):
--JvmOptions="-Duser.dir=C:\LOCAL\serverapps"
Моя конфигурация log4j.properties включает в себя:
log4j.appender.InfoLogFile.File=../logs/info.log
Однако файл info.log записывается в:
C:\WINDOWS\logs
Я проверил значение user.dir во многих разных точках, и это всегда C:\LOCAL\serverapps,
Но log4j ведет себя так, как будто user.dir=C:\Windows\System32 (или какой-то другой C:\Windows).
Из того, что я могу сказать из источника log4j (1.2.16), FileAppender имеет дело только с java.io.FileOutputStream и классы файлов, которые утверждают, что пути относительно user.dir место нахождения.
Я работал над этой проблемой, но мне любопытно: кто-нибудь еще сталкивался с таким типом поведения? Если так, что на самом деле происходит?
3 ответа
FileAppender при задании относительного пути создает файл в текущем рабочем каталоге, а не в домашнем каталоге пользователя.
Вам нужно передать ${user.dir} в имени файла.
РЕДАКТИРОВАТЬ: см. Комментарий ниже для исправления - user.dir!= User.home
Комментарий PhilW указывает на правильный ответ на оригинальный вопрос. То есть Oracle/Sun объявляет о проблеме http://bugs.sun.com/view_bug.do?bug_id=4117557 когда user.dir устанавливается через командную строку. По этой причине относительный путь не понимается должным образом при записи файлов журнала.
Используя абсолютный путь (даже с префиксом ${user.dir} - которому можно доверять на этом этапе - даже если JVM неправильно понимает внутреннее значение), как полагают все Фил, Амир и я, вы вообще избежите этой проблемы.
Я использовал ${user.dir} в lo4j.properties и это сработало. Ты пытался?
log4j.appender.InfoLogFile.File=${user.dir}/logs/info.log