2012-02-25 2 views
2

Когда вы разрабатываете webapp с языком сценариев, у вас есть файл в дереве каталогов вашего проекта, где конфигурации определены во время развертывания и читаются для инициализации во время выполнения. Значительно меняются при развертывании вашего webapp как скомпилированного WAR-файла, потому что у вас нет доступа ни к одному дереву каталогов, ни к обычному редактированию содержимого архива.Файлы конфигурации для WAR-приложений

Это мой сценарий: моему приложению требуется smtp.properties для отправки писем во время выполнения, поэтому этот файл содержит какую-то конфиденциальную информацию, которую я не хочу использовать с другими веб-приложениями. Это означает, что я не буду помещать файл в $CLASSPATH. Другой вариант - проверка в известном месте, но это имеет очевидные проблемы с переносимостью. Просто назвать одно: на Linux у вас есть /etc, на Windows, нет /etc

В настоящее время я прочитал настройки с ServletContext.getInitParameter(String), но это наложить ограничение на формат данных и место фактического файла зависит от контейнера сервлетов.

Итак, мой окончательный ответ: самое ближайшее совпадение с config.php (или config.yml) на земле JavaEE?

Отказ от ответственности: Я прочитал много похожих вопросов, и кажется, что короткий ответ - это не так. Это также громоздко, если вы хотите переопределить настройки для других компонентов во время развертывания (например, ведение журнала)

+0

Это будет трудно сделать на сервере приложений и платформа агностик способом. Наиболее общий способ сделать это, вероятно, будет через системное свойство, определяющее расположение файлов конфигурации, специфичных для среды. Один дополнительный шаг для развертывателя, но его агностик для платформы, и выживет как при повторном развертывании приложений, так и при обновлении сервера приложений. – Perception

+0

Это был мой любимый подход, но он не был прямым, как 'config.php' – Raffaele

ответ

1

В мире Java EE путь является в JNDI. Внутри вашего веб-приложения вы можете прочитать настройки конфигурации с помощью стандартного JNDI API. Это включает в себя что-то вроде учетных данных входа для SMTP, а также, например, настроенных подключений к базе данных.

Для получения дополнительной информации читайте мой ответ на вопрос похожа: How to portably read configuration data from a servlet

+0

Это умный ответ, и я уже посмотрел ваш предыдущий пост, прежде чем задавать свой вопрос. Проблема, с которой я связан, - это безопасность (поскольку я никогда не играл с JNDI): таким образом каждый webapp будет иметь одну и ту же конфигурацию (например, для БД и почты). Кроме того, я не совсем понимаю преимущество использования другого API, когда у вас уже есть параметры init для сервлета. Можете ли вы наметить это? – Raffaele

0

В Java эквивалент файла config.php является окончательно файлом web.xml в WEB-INF. Я не вижу проблемы с the actual file's place depends on the servlet container, вы никогда не указываете путь для чтения параметров внутри, нет?

Кстати, если вы хотите сделать свой собственный файл свойств в войне вы можете Acces его с помощью:

URL propPath = getClass().getResource("your_relative_path"); 
+0

Красота' config.php' заключается в том, что его можно редактировать вручную во время развертывания, в то время как 'WEB-INF/web.xml' недоступен без взрыва (затем переупаковки) WAR. Кроме того, это должен быть XML. С Tomcat можно использовать [this] (http://stackoverflow.com/a/1626190/315306) – Raffaele

+0

Да, если вы хотите редактировать в войне, это будет сложнее, так как вам придется переупаковать войну (и, возможно, обновить сеть .xml, я не знаю, как ...) –

Смежные вопросы