Файлы конфигурации приложения для веб-служб Glassfish/Java EE 5

Я пытаюсь написать несколько простых веб-сервисов Java, чтобы мы могли вызвать Java-код из .NET. До сих пор я получил доказательство концепции, работающей под Glassfish. Довольно просто, когда среда IDE выполняет всю работу.

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

В .NET вы просто вставляете некоторые строки в файл web.config в корень веб-сайта и используете: ConfigurationManager.AppSettings["whateverIwant"];

Я могу получить java.util.Properties, чтобы делать то, что хочу (от автономного клиента), но я не могу понять, где разместить файл .properties и как получить путь к нему из веб-службы.

Мне нужен мой подход к работе в WebSphere Application Server. Спасибо!

Ответы

Ответ 1

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

Как я вижу, это как доказательство концепции, здесь быстрое и грязное решение: (не делайте этого для производственного кода) используйте "Свойства системы". Недостаток: при каждом изменении вам нужно перезагрузить контейнер, но вам не нужно перекомпилировать приложение.

Чтобы использовать свойства системы в Glassfish, вы можете перейти в раздел "Конфигурация → Свойства системы" и добавить туда свойства. Затем изнутри приложения просто вызовите

String myValue = System.getProperty("myProperty");

Чтобы получить значение. Все java-приложения поддерживают эти свойства, но я не знаю, как их настроить в Websphere.

Ответ 2

Увы, Java EE имеет гигантское отверстие в голове, когда дело доходит до конфигурации приложения.

Лучше всего либо:

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

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

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

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

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

см. также: Сохранение и редактирование конфигурации приложений Java EE

Ответ 3

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

  • Сделайте базу данных доступной для вашего приложения (через JNDI, используйте мастер базы данных Glassfish). Это часть зависит от контейнера.
  • Создайте сущность bean, которая десериализует ваши настройки из базы данных. Простое решение здесь - иметь что-то вроде этого:
@Entity
public class Setting {
  @Id
  private String name;
  private String value;
  ...
}

Тогда это вопрос о выполнении em.find(Setting.class, "whateveriwant").getValue(). Кроме того, вы можете создать единый объект bean со всеми параметрами в качестве атрибутов. В любом случае, этот подход уменьшает зависимость контейнера до минимума.

Ответ 5

Поместите следующий код в contextInitialized метод ServletContextListener:

ServletContext sc = sce.getServletContext();
Properties systemProps = System.getProperties();            
String path = sc.getRealPath("WEB-INF/application.properties");
systemProps.load(new FileInputStream(path));

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