Ссылки на переменные среды в web.xml - PullRequest
31 голосов
/ 10 сентября 2009

Я предварительно упаковываю веб-приложение JSP, которое использует некоторые настройки пути к файлу, найденные в web.xml. Эти параметры неизвестны во время упаковки, потому что они ссылаются на путь, который клиент будет указывать при развертывании всего приложения (веб-приложение которого является интерфейсом управления).

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

Есть ли способ ссылаться на значение переменной среды из web.xml? Поиски в Google приводят к методу J2EE УСТАНОВКИ переменных среды из файлов ejb xml. Это не то, что я ищу.

Ответы [ 6 ]

35 голосов
/ 16 октября 2013

Вы можете использовать подстановку переменных в стиле Ant в любом из файлов конфигурации tomcat xml, например:

<servlet-mapping>
    <servlet-name>mvc-dispatcher</servlet-name>
    <url-pattern>${foo}</url-pattern>
</servlet-mapping>

Где foo - это Системное свойство Java (sysprop).

Вы не можете использовать Переменные среды ОС (envvars) напрямую, я думаю ...

Чтобы использовать envvars, вы можете поставить

set "CATALINA_OPTS=-DsomeJavaSysProp=%SOME_OS_ENVVAR%"

в bin/setenv.bat (или аналогично в bin/setenv.sh для * nix). Вам может понадобиться создать этот файл. Tomcat запустит этот файл при запуске.

Поскольку CATALINA_OPTS является envvar (в отличие от параметра командной строки), он не должен быть виден другим пользователям в системе (кроме древних Unixes), хотя я не проверял это.

http://tomcat.apache.org/tomcat-7.0-doc/config/

Если вы используете Spring, вы можете создать бин <context:property-placeholder/>, а затем напрямую использовать envvars или sysprops в конфигурационных файлах Spring XML (но не web.xml).

11 голосов
/ 11 сентября 2009

я думаю, что вы не хотите использовать переменные окружения (которые, я думаю, недоступны из web.xml), но окружение записи [ 1 , 2 ]. вот так:

<env-entry>
    <env-entry-name>Bla/SomeFilePath</env-entry-name>
    <env-entry-type>java.lang.String</env-entry-type>
    <env-entry-value>/opt/bla</env-entry-value>
</env-entry>

вы можете использовать SomeFilePath как:

InitialContext ic = new InitialContext();
String s = (String) ic.lookup("java:comp/env/ejb/Bla/SomeFilePath");
8 голосов
/ 05 января 2011

По сути, вы так не делаете. web.xml должен содержать значения по умолчанию для вещей, да, но вы должны переопределить их при фактическом выполнении развертывания. Если вы развертываете в Tomcat, вы делаете это, включая соответствующие записи в context.xml, который вы используете для развертывания. Например:

<Context path="/app">
    <!-- For things described by webapp parameters -->
    <Parameter name="foobar" value="grill" />

    <!-- For things described by environment entries -->
    <Environment name="Bla/SomeFilePath" type="java.lang.String"
            value="/opt/bla" />
</Context>

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

1 голос
/ 20 июля 2018

Переменные окружения могут быть доступны в XML-файлах, например:

${env.ENVIRONMENT_VARIABLE_NAME}

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

1 голос
/ 20 апреля 2014

Вы должны поместить запись env в порядок:

<env-entry>
  <env-entry-name>maxAmount</env-entry-name>
  <env-entry-type>java.lang.String</env-entry-type>
  <env-entry-value>aString</env-entry-value>
</env-entry>

В противном случае у вас будет ошибка проверки на web.xml

ref: https://community.oracle.com/thread/840452?tstart=0

1 голос
/ 21 ноября 2013

Я не совсем понимаю ваши ограничения, но, может быть, вы можете сделать это (я предполагаю, что вы пытаетесь настроить init-параметр):

1) Оставьте переменную неуказанной в web.xml
2) Создайте ServletContextListener и добавьте это в ваше приложение
3) Прослушайте инициализацию вашего сервлета
4) Установите init-param для сервлета в этой точке

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

...