WebSphere и PropertyPlaceholderConfigurer - PullRequest
1 голос
/ 11 августа 2009

Я большой пользователь свойств (с PropertyPlaceholderConfigurer) для того, чтобы сделать мое приложение максимально динамичным. Почти все константы определены как таковые. В любом случае, в настоящее время я определяю default.properties, который поставляется с WAR по умолчанию.

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

<bean id="propertyManager"
        class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
        <property name="locations">
            <list>
                <value>classpath:com/company/default.properties</value>
                <value>file:${COMPANY_PROPERTIES_LOCATION}\kbo-select-settings.properties</value>
            </list>
        </property>
    </bean>

Благодаря этому я могу использовать промо-сборку для каждой среды.

ОДНАКО, мне не нравится тот факт, что я не могу изменить какие-либо свои свойства изнутри WebSphere. Вместо этого мне нужно перейти на каждый из серверов (у нас их 8 кластеров) и соответственно изменить свойства. Было бы намного удобнее для пользователя, если бы я мог изменить их изнутри WebSphere и просто выполнить перезапуск потом ...

У кого-нибудь есть идеи о том, как я могу сделать такую ​​промо-сборку? Я уже определяю конфигурацию JNDI для источников данных / Java-почты / и т. Д.

Спасибо!

Ответы [ 5 ]

2 голосов
/ 11 августа 2009

Мы решили эту проблему, используя расширение файла свойств для каждой среды (local, dev, int, tst ...), и каждый файл содержал определенные значения для этих сред. Единственное добавление, которое вам требуется, - это аргумент виртуальной машины на сервере, который должен быть установлен -Druntime.env = X.

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

<bean id="propertyManager"
 class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="locations">
       <list>
          <value>classpath:com/company/default.properties.${runtime.env}</value>
          <value>file:${COMPANY_PROPERTIES_LOCATION}\kbo-select-settings.properties</value>
        </list>
    </property>
 </bean>

Конечно, это работает, только если у вас достаточно статичная среда, поскольку она по-прежнему не может быть изменена во время выполнения, но делает продвижение приложения очень простым. Если вы хотите иметь возможность изменять значения без повторного развертывания приложения, вам придется хранить их вне приложения, что вы, похоже, уже делаете для kbo-select-settings.properties

1 голос
/ 08 декабря 2009

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

<!--  try to lookup the configuration from a URL, if that doesn't work, fall back to the properties on the classpath -->
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="location">
        <bean class="org.springframework.core.io.UrlResource">
            <constructor-arg>
                <jee:jndi-lookup 
                    jndi-name="url/config" 
                    default-value="file:///tmp" /> <!--  dummy default value ensures that the URL lookup doesn't fall over if the JNDI resource isn't defined -->
            </constructor-arg>
        </bean>
    </property>
    <property name="properties">
        <bean class="org.springframework.beans.factory.config.PropertiesFactoryBean">
            <property name="locations">
                <list>
                    <value>classpath:com/company/default.properties</value>
                </list>
            </property>
        </bean>
    </property>
    <property name="ignoreResourceNotFound" value="true"/> 
</bean>

Таким образом, вы можете указать разные имена файлов для разных сред, используя консоль WAS в разделе «Ресурсы> URL> URL», создав ресурс с JNDI-именем «url / config» и указав его на правильный файл (file: // /your/path/to/properties).

В качестве альтернативного решения, если вы хотите управлять отдельными свойствами через консоль, вы вместо использования PropertyPlaceholderConfigurer можете использовать jee: jndi-lookup для получения значений из env-записей web.xml (которыми вы можете управлять с помощью консоль WAS). См. этот ответ

0 голосов
/ 24 августа 2009

Способ, которым я имел дело с этим, состоит в том, чтобы использовать значения свойств в JVM, а затем ссылаться на них в переменной WebSphere, которая определена на уровне cluser или ячейки. Например, скажем, что вы хотите, чтобы значение с именем value1 было установлено в param1 в конфигурации Spring, вы должны сделать следующее:

<bean id="propertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer" />

И тогда что-то вроде следующего, ссылается на переменную:

<bean id="id" class="com.blah.class">
        <property name="value1" value="${param1}" />
</bean>

Тогда в рамках ваших тестов вы можете настроить свои тесты следующим образом:

/**
     * @see org.springframework.test.AbstractSingleSpringContextTests#prepareApplicationContext(org.springframework.context.support.GenericApplicationContext)
     */
    @Override
    protected void prepareApplicationContext(GenericApplicationContext context) {
        System.setProperty("param1", "myvalue");
        }

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

Для этого создайте переменную JVM с именем:

param1

со значением $ {webspherevar.param1}

А затем создайте переменную WebSphere с именем:

webspherevar.param1

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

Надеюсь, это поможет.

0 голосов
/ 12 августа 2009

Добавление ресурса URL, который указывает на ваши файлы конфигурации, на ваши серверы Websphere, а затем поиск этого в вашем приложении - это жизнеспособный путь. Затем вы можете настроить URL-адрес так, чтобы он указывал на центральное расположение, где все файлы конфигурации управляются - если вы используете svn и ваш svn имеет доступ только для чтения, вы можете даже напрямую читать их из svn (через http).

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

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

0 голосов
/ 11 августа 2009

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

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

Один подход описан здесь Keys Botzum,

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

Другой вариант - использовать базу данных для конфигурации. В наши дни поппин XML в БД, такой как DB2, не очень сложен.

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