Как лучше всего хранить файл конфигурации в веб-приложении Java (WAR)?


Я создаю веб-приложение (WAR) и развертываю его на Tomcat. В webapp есть страница с формой, где администратор может ввести некоторые данные конфигурации. Я не хочу хранить эти данные в СУБД, а только в XML-файле в файловой системе. Куда его девать?

Я хотел бы поместить файл где-нибудь в дереве каталогов, где развернуто само приложение. Если мой файл конфигурации находится в WEB-INF? Или положить его где-то еще?

и что такое код Java для использования в сервлете, чтобы найти абсолютный путь к каталогу? Или к нему можно получить доступ с относительным путем?

6 54

6 ответов:

то, что мы делаем, это поместить его в отдельный каталог на сервере (вы можете использовать что-то вроде /config, /opt/config, /root/config, /home/username/config или все, что вы хотите). Когда наши сервлеты запускаются, они читают XML-файл, получают из него несколько вещей (самое главное, информацию о подключении к БД), и все.

Я спросил о том, почему мы сделали это один раз.

было бы неплохо хранить все в БД, но, очевидно, вы не можете хранить информацию о подключении к БД в БД.

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

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

файл в специальном месте на файловой системе вещь работает довольно хорошо для нас. У него нет больших недостатков. Вы знаете, где он находится, он хранится отдельно, упрощает развертывание на нескольких машинах, если всем им нужны разные значения конфигурации (поскольку это не часть войны).

единственное другое решение, которое я могу придумать, что будет хорошо работать будет держать все в БД, кроме информации для входа в БД. Это будет происходить из системных свойств Java, которые извлекаются через JVM. Это предпочтения API вещь, упомянутая Ханс доджен выше. Я не думаю, что это было вокруг, когда наше приложение было впервые разработано, если оно не было использовано.

Что касается пути для доступа к файлу конфигурации, это просто файл в файловой системе. Вам не нужно беспокоиться о веб-путь. Поэтому, когда ваш сервлет запускается, он просто открывает файл в "/config / myapp / config.xml " (или что-то еще), и он найдет правильную вещь. Просто жесткое кодирование пути для этого кажется мне довольно безвредным.

WEB-INF-это хорошее место для размещения вашего файла конфигурации. Вот некоторый код, чтобы получить абсолютный путь к каталогу, из сервлета.

public void init(ServletConfig servletConfig) throws ServletException{
    super.init(servletConfig);
    String path = servletConfig.getServletContext().getRealPath("/WEB-INF")

положить его в WEB-INF скроет XML-файл от пользователей, которые пытаются получить к нему доступ непосредственно через URL, так что да, я бы сказал, положить его в WEB-INF.

Я бы не стал хранить его в папке приложения, потому что это переопределит конфигурацию с новым развертыванием приложения.

Я предлагаю вам взглянуть на API настроек или написать что-то в папке users (пользователь, который работает с Tomcat).

ответ на этот вопрос зависит от того, как вы намерены читать и писать, что файл config.

например, Spring framework дает вам возможность использовать файлы конфигурации XML (или файлы свойств Java); они могут храниться в вашем classpath (например, в каталоге WEB-INF), в любом другом месте файловой системы или даже в памяти. Если вы должны были использовать Spring для этого, то самое простое место для хранения файла конфигурации находится в вашем каталоге WEB-INF, а затем использовать Spring ClassPathXmlApplicationContext класс для доступа к файлу конфигурации.

но опять же, все зависит от того как вы планируете получить доступ к этому файлу.

Если это ваш пользовательский config WEB-INF является хорошим местом для него. Но некоторые библиотеки могут требовать, чтобы конфигурации находились в WEB-INF/classes.