WebSphere und PropertyPlaceholderConfigurer

Question

Ich bin ein großer Benutzer von Eigenschaften (mit PropertyPlaceholderConfigurer), um meine Anwendung so "dynamisch" wie möglich zu machen. Fast alle Konstanten sind als solche definiert. Wie auch immer, ich definiere gerade eine default.properties, die mit dem Standard WAR ausgeliefert wird.

In anderen Umgebungen (Annahme/Produktion) muss ich die Konfigurationen überschreiben. Ich mache das wie folgt:

Mit diesem Mittel kann ich einen promotable Build für jede der Umgebungen verwenden.

ABER ich mag nicht die Tatsache, dass ich keine meiner Eigenschaften von innerhalb von WebSphere ändern kann. Stattdessen muss ich zu jedem der Server gehen (wir haben 8 geclustert) und die Eigenschaften entsprechend ändern. Es wäre viel benutzerfreundlicher, wenn ich die Änderungen innerhalb von WebSphere ändern und anschließend einen Neustart durchführen könnte ...

Jeder hat eine Idee, wie ich solch einen promotable Build machen könnte? Ich definiere bereits JNDI-Konfiguration für Datenquellen/Java Mail/etc.

Danke!

Answer 1

Wir haben dieses Problem gelöst, indem wir eine Erweiterung der Eigenschaftendatei für jede Umgebung (local, dev, int, tst ...) verwendeten und jede Datei bestimmte Werte für diese Umgebungen enthielt. Die einzige Ergänzung, die Sie dann benötigen, ist ein VM-Argument auf dem Server, um -Druntime.env = X zu setzen.

Ihre Lookups in Ihrer Konfigurationsdatei sieht dann wie dieses

<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> 

Natürlich funktioniert dies nur, wenn Sie ziemlich statische Umgebungen haben, da sie sich selbst noch nicht leihen es zur Laufzeit zu ändern, aber es macht die Förderung der Anwendung todt einfach. Wenn Sie die Werte zu ändern, ohne Umschichtung Ihre Anwendung in der Lage sein wollen, müssen Sie sie vor der Anwendung gespeichert haben, die bereits Sie scheinen für die kbo-select-settings.properties zu tun

Answer 2

Wenn die Konfiguration in der EAR-Datei ist, dann kenne ich keine einfache Möglichkeit, Änderungen ohne Backdoor-Cheats zu propagieren oder die App erneut zu implementieren.

Ich denke, dass die Konfiguration, speziell das, was sich ändert, wenn Sie die App promoten, nicht in die Anwendung sein sollte.

Ein Ansatz ist here von Keys Botzum, beschrieben

Hinweis, dass man tatsächlich propagieren Dateien, die nicht Teil einer bestimmten Anwendung, um Knoten mit Standard-WebSphere-Synchronisation sind.

Eine weitere Option ist die Verwendung einer Datenbank für die Konfiguration. Heutzutage packt XML in eine Datenbank wie DB2 nicht sehr schwer.

Answer 3

ein Hinzufügen Eine URL-Ressource, die auf Ihre Konfigurationsdateien zu Ihren Websphere-Servern zeigt und dann in Ihrer Anwendung nachschlägt, ist ein praktikabler Weg. Sie können dann die URL so konfigurieren, dass sie auf einen zentralen Ort verweist, an dem alle Konfigurationsdateien verwaltet werden. Wenn Sie svn verwenden und Ihr svn nur Lesezugriff hat, können Sie sie sogar direkt von svn (über http) lesen.

Frühling hat einige eingebaute Einrichtungen dafür, und es bedeutet auch, dass Sie verschiedene Konfigurationsdateien Prioritäten setzen können.

Weitere Informationen finden Sie aktuelle how-to-differentiate-between-test-and-production-properties-in-an-application

Answer 4

Die Art und Weise, die ich behandelt habe mit diesen Eigenschaftswerte auf der JVM zu verwenden ist, aber dann sie zu einem WebSphere-Variable verweisen, die auf der cluser oder Zellebene definiert ist. Zum Beispiel, sagen Sie ein Wert wollen in param1 im Frühjahr Konfiguration namens value1 gesetzt würden Sie wie folgt vor:

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

Und dann so etwas wie wie folgt die Variable Sie verweisen:

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

dann innerhalb Ihre Tests Einrichtung Ihres Tests können wie folgt:

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

Dann aus der WebSphere-Konfiguration, wenn Sie eine JVM Variable erstellen und an die WebSphere verlinken Variable Sie müssen nur die WebSphere-Variable ändern und es wird automatisch alle JVM-Variablen auf jedem Rechner aktualisieren.

Um dies zu tun, erstellen Sie eine JVM Variable mit dem Namen:

param1

mit einem Wert von $ {} webspherevar.param1

Und dann ein WebSphere-Variable erstellen genannt:

webspherevar .param1

Das enthält, was auch immer der Wert ist, den Sie hineinlegen müssen. Auf diese Weise können Sie die Werte für jede Umgebung nicht versenden und stattdessen in die Umgebung laden und verwenden.

Ich hoffe, das hilft.

Answer 5

Ein potenzielles Problem besteht darin, dass Sie den Speicherort Ihrer Eigenschaftendatei fest codieren. Sie könnten die Position der Eigenschaftendatei als JNDI Ressource angeben und auf dem Classpath angegeben auf die Standardeinstellungen zurückzufallen:

<!-- 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> 

Auf diese Weise können unterschiedliche Dateinamen für verschiedene Umgebungen festlegen können die WAS-Konsole in Ressourcen> URL > URLs, indem Sie eine Ressource mit dem JNDI-Namen "url/config" erstellen und auf die richtige Datei verweisen (file: /// your/path/to/properties). Wenn Sie einzelne Eigenschaften über die Konsole verwalten möchten, können Sie anstelle von PropertyPlaceholderConfigurer mit jee: jndi-lookup Werte aus den web.xml env-entries (die Sie verwalten können) abrufen Verwenden der WAS-Konsole). Siehe this answer