Динамическое получение имени файла свойств в EJB Jar (развернуто в ухе)

При создании/развертывании военных файлов я использую в своем файле web.xml, чтобы определить, какой файл свойств использовать:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
    version="3.0">
    <context-param>
        <param-name>PropertiesFile</param-name>
        <param-value>/path/to/my.properties</param-value>
    </context-param>
    <display-name>MyServlet</display-name>
    <servlet>
        <servlet-name>MyServlet</servlet-name>
        <servlet-class>com.my.company.MyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>MyServlet</servlet-name>
        <url-pattern>/*</url-pattern>
    </servlet-mapping>
</web-app>

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

public void init(ServletConfig config) throws ServletException
{
    super.init(config);

    log.debug("Enter init()");

    // get the properties location from web.xml
    String propertiesFile = config.getServletContext()
            .getInitParameter("PropertiesFile");

    log.info("Using properties file: " + propertiesFile);

    // Finish intiliazing...
}

Есть ли что-то похожее (или совершенно другое) для установки/получения файла свойств для уха, содержащего банку EJB, без жесткого кодирования в моем классе? Файл свойств не будет включен ни в банку, ни в ухо, а будет расположен на сервере за пределами сервера приложений.


person sdoca    schedule 22.11.2011    source источник


Ответы (1)


Вы можете использовать записи среды и внедрять их с помощью @Resource для достижения желаемого.

Взгляните на этот пример OpenEJB.

Однако, если вы скажете что-то вроде:

Файл свойств не будет включен ни в банку, ни в ухо, а будет расположен на сервере за пределами сервера приложений.

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

person Piotr Nowicki    schedule 22.11.2011
comment
Спасибо за ссылку; Я посмотрю на это. Причина, по которой файлы свойств не включены в jar/ear, заключается в том, что они различаются в зависимости от того, на какую систему мы развертываем (например, lab, prod). Причина использования файлов свойств в первую очередь заключается в том, что они могут изменяться. Какую версию свойств вы включаете, лабораторную или производственную? А что, если вы случайно перезапишите свойства prod на lab из-за повторного развертывания приложения? - person sdoca; 23.11.2011
comment
@sdoca просто учтите это, так как вас предупредили :-) Кстати, свойства вашей лаборатории / продукта изменяются каким-то другим процессом, кроме вашего приложения, и поэтому вы не можете включить его в свое приложение? - person Piotr Nowicki; 23.11.2011
comment
Итак, основываясь на предоставленной вами ссылке, я заставил ее работать. Спасибо! У меня уже был класс Singleton в моей банке, который содержал константы для различных используемых ключей свойств, поэтому было естественным поставить @Resource для пути к файлу. Я создал метод для загрузки свойств и аннотировал его аннотацией @PostConstruct, а класс аннотировал аннотацией @Startup, чтобы обеспечить его загрузку. - person sdoca; 23.11.2011
comment
Отлично, звучит очень разумно :-) - person Piotr Nowicki; 23.11.2011
comment
Мое приложение читает файл свойств, а не устанавливает их. Считайте, что я предупрежден. Хотя я без проблем использовал файлы внешних свойств в течение многих лет для своих веб-/военных приложений, поэтому я думаю, что я в безопасности. :) - person sdoca; 23.11.2011