Как вы получаете путь к файлу при изменении каталога пользователя? - PullRequest
0 голосов
/ 15 сентября 2009

У меня есть приложение Java, и файл log4j.properties находится в src / com / my / path / props. При компиляции он копируется в классы / com / my / path / props

Файл загружается через PropertyConfigurator.configureAndWatch (user.dir + "/classes/com/my/path/props/log4j.properties").

Все это нормально работает, хотя и не идеально из-за использования user.dir (но я не знаю другого способа ссылки на файл относительно "начального каталога приложения"). Проблема проявляется при попытке запустить это приложение с помощью оболочки службы NT. После этого user.dir переходит из корневого каталога приложения в любое место, где находится исполняемый файл оболочки NTService.

Мой вопрос: как правильно получить представление пути к файлу String файла log4j.properties в каталоге Мои классы / com / my / path / props /? Я понимаю, что это полностью сломалось бы, если бы файл реквизита был в банке; но в данном случае это не просто файл в файловой системе.

Я пробовал новый файл (this.getClass (). GetClassLoader (). GetResource ("com / my / path / props / log4j.properties"). GetURI ()). GetAbsolutePath (), но это не удалось, поскольку на производстве путь к файлу на самом деле является UNC-путем и, следовательно, выдает исключение «URI имеет компонент полномочий».

Как другие люди решают эту проблему?

Спасибо.

Ответы [ 2 ]

1 голос
/ 15 сентября 2009

OK. Итак ... вы спросили, как другие люди справляются с этой проблемой. Во-первых, они не оставляют это на Eclipse, где размещаются файлы. Они выбирают, где они хотят их, как они хотят получить к ним доступ, и затем имеют свой инструмент сборки (который, если они просто не играют, не должен быть IDE, подобным Eclipse, а скорее специализированным инструментом сборки, таким как Maven или Ant), где поместите это.

Выбор того, где вы хотите файл, зависит от того, что вы хотите с ним делать. Если это просто файл конфигурации, который никогда не будет редактироваться во время выполнения, вы обычно помещаете его в свой JAR (что является еще одной практикой - приложения помещаются в один или несколько JAR, WAR или EAR, а не в каталог классов). Если файл должен быть отредактирован во время выполнения, что, исходя из вашего «просмотра», кажется, имеет место, вы обычно помещаете его в каталог конфигурации вне вашего JAR.

Другой способ выбора способа доступа к нему (из пути к файлу или пути к классам). Там, где это возможно, я предпочитаю доступ к файлам из classpath, потому что он более переносим - а в JAR это в значительной степени требуется. Если это не имеет смысла в вашем случае, тогда выберите путь, отличный от «user.dir», если он меняется при развертывании. Вы можете жестко закодировать его, использовать переменную окружения, свойство, файл конфигурации, аргумент командной строки и т. Д., Чтобы установить фактический путь.

Всегда выбирайте, куда идут вещи и как вы к ним обращаетесь. Не позволяйте вашим инструментам выбирать за вас. Это сделает вашу жизнь проще: -)

0 голосов
/ 16 октября 2009

Я воспользовался советом singleshot и сохранил файлы свойств из src, а не в отдельном каталоге, который я добавил в classpath. В ретроспективе, это было действительно глупо, чтобы настроить его так, как я делал изначально.

Оттуда моей проблемой было получение файла по URL. В итоге я нашел то, что мне нужно, в Commons IO FileUtils с его методом toFile (URL) .

Код в итоге выглядел так:

private URL maintenanceConfigPath = this.getClass().getClassLoader().getResource("MaintenanceConfig.properties");
....
File f = FileUtils.toFile(maintenanceConfigPath);
....

Опять же, спасибо всем за ваши отзывы и за то, что вы указали мне путь, по которому я получил ответ

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...