Динамически получить свойства Имя файла в EJB Jar (развернуто в ear) - PullRequest
2 голосов
/ 23 ноября 2011

При создании / развертывании военных файлов я использую в своем 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>

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

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-банку, без жесткого кодирования в моем классе? Файл свойств не будет включен ни в банку, ни в ухо, но находится на сервере вне сервера приложений.

1 Ответ

1 голос
/ 23 ноября 2011

Вы можете использовать записи среды и вводить их, используя @Resource, чтобы достичь того, что вы хотите.

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...