Frage

Ich möchte zum speichern der Konfiguration für ein web-Projekt außerhalb des web-Projekts (ear/war-Datei).Die Anwendung sollte nicht wissen, in welchem container es läuft (WebSphere/JBoss, etc.).

Was ist der beste Weg, dies zu behandeln?

Ist JNDI ein sauberer Weg?Wenn JNDI kann meine Probleme zu lösen, wie sollte ich es konfigurieren?(Benutzerdefinierte Objekte?)

In meinem Fall sind es nur einfache Schlüssel=>Wert-Paare (String,String) für SOAP/WS-Endpunkten.

War es hilfreich?

Lösung

Diese finden Sie unter Frage zum Lesen Eigenschaften Datei außerhalb der war-Datei.

Diese finden Sie unter Frage zum Lesen variable Werte von JNDI.Ich glaube, dass dies die beste Lösung.Lesen Sie eine String-variable mit diesem code:

Context initialContext = new InitialContext();
String myvar = (String) initialContext.lookup("java:comp/env/myvar");

Der obige code funktioniert auf allen Behältern.In Tomcat erklären Sie die folgenden in conf/server.xml:

<GlobalNamingResources ...>
  <Environment name="myvar" value="..."
         type="java.lang.String" override="false"/>
</GlobalNamingResources>

Die oben erstellen Sie eine Globale Ressource.Es ist auch möglich, eine Ressource definieren, die im Kontext der Anwendung.In den meisten Container, die der JNDI-Ressourcen verfügbar sind durch einen MBeans Management Console.Einige von Ihnen bieten eine grafische Oberfläche, um Sie zu Bearbeiten.Höchstens ein Neustart der Anwendung ist erforderlich, wenn eine änderung vorgenommen wird.

Wie JNDI-Ressourcen werden definiert und bearbeitet container-spezifisch.Es ist die Aufgabe der configurator/administrator wenden Sie die entsprechenden Einstellungen.

Dies sind die Vorteile von JNDI:

  • Definieren Sie die Standardwerte der Parameter in den WAR/EAR-Datei.
  • Parameter sind leicht konfigurierbar in den container.
  • Sie nicht brauchen, um starten Sie den container, wenn Sie ändern Sie den Wert eines Parameters.

Andere Tipps

Wir hatten eine ähnliche Konfiguration erforderlich, wenn die Bereitstellung einer Web-App für verschiedene Entwickler, und auf Amazon ' s EC2:wie tun wir separate Konfiguration aus den binären code?In meiner Erfahrung, JNDI ist zu Komplex, und schwankt zu sehr zwischen den Behältern verwendet werden.Auch hand-Bearbeitung von XML ist sehr anfällig für Fehler in der syntax, also war die Idee wurde verworfen.Wir haben dieses Problem gelöst, mit einem design basiert auf einigen Regeln:

1) nur einfach ein name=Wert-Einträgen verwendet werden sollte

2) neue Konfigurationen sollten belastbar sein, indem Sie nur einen parameter ändern

3) unser KRIEG binären muss rekonfigurierbare w/o Umpacken es

4) empfindlicher Parameter (Passwort) werden niemals verpackt in das Binär

Verwenden .properties-Dateien für alle Konfigurations -, und mit System.getProperty("domain"); laden Sie die entsprechenden Eigenschaften-Dateien, wir waren in der Lage, die Anforderungen zu erfüllen.Jedoch, die system-Eigenschaft nicht in eine Datei-URL statt, erstellten wir ein Konzept nennen wir "domain" angeben, um die Konfiguration zu verwenden.Der Speicherort der Konfiguration wird immer:
$HOME/appName/config/$DOMAIN.properties.

Also wenn ich das ausführen möchte meine app mit meine Konfiguration, ich starte die app, indem Sie die Einstellung des domain auf meinen Namen:
-Ddomain=jason
auf Start, und die app lädt die Datei:
/home/jason/appName/config/jason.properties
Dies ermöglicht Entwicklern teilen, Konfigurationen, so dass wir können neu erstellen, die gleichen Zustand der app zum testen und deployment, ohne ein neues oder Umpacken.Der domain-Wert wird dann verwendet, um zu laden .Eigenschaften vom standard-Speicherort außerhalb des gebündelten KRIEG.

Ich kann völlig neu erstellen Sie die Produktionsumgebung auf meiner Arbeitsstation mit der Produktion Konfiguration wie:
-Ddomain=ec2 das wäre zu laden:
/home/jason/appName/config/ec2.properties

Dieses setup ermöglicht es uns zu tun haben dev/QA/release-Zyklen mit genau einem Satz von kompilierten Binärdateien, mit verschiedenen Konfigurationen in jede Umgebung.Es gibt kein Risiko, dass Passwörter in/etc gebündelt in der Binärdateien, und die Menschen können teilen Sie Ihre Konfigurationen zu erstellen Probleme, die wir sehen.

Ich verwende eine environment-variable zeigt auf eine URL (das ist wahrscheinlich einer Datei:// URL), die eigene Konfiguration.Dies ist sehr einfach zu installieren und nicht erfordern den JNDI-Infrastruktur.

Hier einige Beispiel-code (tippte aus dem Gedächtnis habe ich noch nicht kompiliert/getestet):

public void loadConfiguration() {
   String configUrlStr = System.getenv("CONFIG_URL"); // You'd want to use a more
                                                      // Specific variable name.
   if(configUrlStr == null || configUrlStr.equals("") {
       // You would probably want better exception handling, too.
       throw new RuntimeException("CONFIG_URL is not set in the environment."); 
   }


   try {
       URI uri = new URI(configUrlStr);
       File configFile = new File(uri);
       if(!configFile.exists()) {
          throw new RuntimeException("CONFIG_URL points to non-existant file");
       }
       if(!configFile.canRead()) {
          throw new RuntimeException("CONFIG_URL points to a file that cannot be read.");
       }
       this.readConfiguration(configFile);
   } catch (URISyntaxException e) {
       throw new RuntimeException("Malformed URL/URI in CONFIG_URL");
   }



}

Sie können einfach speichern, dann ist eine normale java-properties-Datei, die auf dem Klassenpfad und laden Sie einfach die Eigenschaften?

es ist unkompliziert und ziemlich einfach..es sei denn, ich bin etwas fehlt

Meine Favoriten sind :Environment-Variablen und Properties-Dateien (wie vorgeschlagen von Jared und kgiannakakis oben.)

Datenbank-Tabelle zu speichern Umwelt Eigenschaften

Jedoch eine andere, einfachere Lösungen, um die Datenbank-Tabelle zu speichern Umwelt Eigenschaften.

Wenn die Anwendung verwendet die Datenbank

  • dies ist relativ einfach zu setup
  • Gibt wirklich einfach zu kontrollieren/ändern von Werten
  • Es können integriert werden in dem Prozess auch, indem es einen Teil der DB-Skripte
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top