Определить, работает ли в контейнере сервлетов или автономно

Question

У меня есть простая проблема: я хочу настроить объект по-разному в зависимости от того, создается ли объект в контейнере сервлета или создается ли он в отдельном приложении.

Объект является подключением к базе данных, и я забочусь о настройке тайм-аутов запросов.

Первое решение, которое я могу предложить, это:

if (insideServletContainer(this.getClass().getClassLoader()) { 
  /// do some servlet specific config
}
else {
 /// do some standalone config
}

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

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

Итак, подытожив мой вопрос: : Вам известен хороший / надежный механизм, если класс был загружен из контейнера сервлета? Если нет, я буду по второму маршруту.

Ник

Answer 1

Если не учитывать, является ли это хорошей идеей, я бы предложил поискать java: comp / env, которая будет доступна только на сервере EE:

try {
  new InitialContext().lookup("java:comp/env");
  /// do some servlet specific config
} catch (NamingException ex) {
  /// do some standalone config
}

Answer 2

Это похоже на действительно плохую идею. Вместо этого, почему бы вам не позволить классу принимать параметры, а затем позволить контейнеру или приложению настроить его соответствующим образом?

Answer 3

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

В автономной версии это может быть сделано методом main() (или чем-то вызванным из него).

В версии веб-приложения это будет сделано слушателем или вызванным фильтром, настроенным в web.xml.

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

Answer 4

Я бы порекомендовал Inpendency Injection, как @matt b.

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

db_prop.dev
db_prop.stalone
dp_prop.int
db_prop.prod

Тогда вы можете загрузить ресурс

"db_prop." + System.getProperty("runtime.env")