Ich versuche, implementierungsspezifische Informationen aus einer Eigenschaftendatei in meinem Wildfly-Konfigurationsordner zu lesen. Ich habe es versucht:
%Vor%Aber anscheinend funktioniert das nicht, da der Konfigurationsordner nicht mehr im Klassenpfad ist. Jetzt kann ich keinen einfachen Weg finden, es zu tun. Mein Favorit wäre etwa so:
%Vor%Die einzige Lösung, die ich bisher im Web gefunden habe, ist das Erstellen meines eigenen OSGi-Moduls, aber ich glaube, dass es einen einfacheren Weg dafür geben muss (einen ohne OSGi!). Kann mir jemand wie zeigen?
Wenn Sie explizit eine Datei aus dem Konfigurationsverzeichnis lesen möchten (z. B. $WILDFLY_HOME/standalone/configuration oder domain/configuration ), gibt es eine Systemeigenschaft mit dem Pfad darin. Führen Sie einfach System.getProperty("jboss.server.config.dir"); aus und hängen Sie den Dateinamen an diesen an, um die Datei zu erhalten.
Sie würden es jedoch nicht als Ressource lesen, also ...
%Vor%Dann würde die Datei für Sie geladen werden.
Da WildFly nicht mehr mit OSGi-Unterstützung ausgeliefert wird, weiß ich auch nicht, wie das Erstellen eines OSGi-Moduls hier helfen würde.
Hier ist ein vollständiges Beispiel, das nur CDI verwendet, aus diesem Website .
Erstellen und füllen Sie eine Eigenschaftendatei im WildFly-Konfigurationsordner
%Vor%Fügen Sie der WildFly-Konfigurationsdatei eine Systemeigenschaft hinzu.
%Vor%Dies fügt Ihrer Server-Konfigurationsdatei (standalone.xml oder domain.xml) Folgendes hinzu:
%Vor%Erstellen Sie die Singleton-Session-Bean, die die anwendungsweiten Eigenschaften lädt und speichert
%Vor%Erstellen Sie den CDI-Qualifier. Wir werden diese Annotation für die Java-Variablen verwenden, in die wir injizieren möchten.
%Vor%Erstellen Sie die Producer-Methode; Dies erzeugt das zu injizierende Objekt
%Vor%Schließlich injiziere die Eigenschaft in eine deiner CDI-Beans
%Vor% Am einfachsten können Sie standalone.sh mit einer -P -Option ausführen, die auf Ihre Eigenschaftendatei verweist (Sie benötigen eine URL file:/path/to/my.properties , oder fügen Sie die Datei in $WILDFLY_HOME/bin ein).
Dann werden alle Eigenschaften aus der Datei als Systemeigenschaften geladen.
Um Konfigurationseigenschaften in Ihre Anwendungsklassen zu injizieren, schauen Sie sich DeltaSpike-Konfiguration an, die verschiedene unterstützt Property-Quellen wie Systemeigenschaften, Umgebungsvariablen, JNDI-Einträge und verbirgt die spezifische Quelle aus Ihrer Anwendung.
Alternativ können Sie, um das Festlegen von Systemeigenschaften zu verhindern (die global für alle in Ihrer WildFly-Instanz bereitgestellten Anwendungen sichtbar sind), eine benutzerdefinierte Eigenschaftsquelle für DeltaSpike definieren, die eine Eigenschaftendatei von einem beliebigen Speicherort liest. und diese Eigenschaften werden für Ihre Anwendung lokal sein.
Es scheint, als ob das Problem, das Sie zu lösen versuchen, die Verwaltung verschiedener (aber wahrscheinlich ähnlicher) Konfigurationsdateien für die Ausführung Ihrer Anwendung in verschiedenen Umgebungen (z. B. Produktion, Qualitätssicherung oder sogar unterschiedliche Kunden) ist. Wenn das der Fall ist, werfen Sie einen Blick auf Jfig Ссылка . Es würde die Notwendigkeit für das Speichern von Eigenschaftendateien außerhalb Ihres Klassenpfads überflüssig machen (aber Sie könnten es immer noch tun).
Was benötigt wird, ist ein hierarchischer Ansatz für Konfigurationsdateien. Die neunzig Prozent der Konfigurationswerte, die sich nicht ändern, können in einer Basisdatei verwaltet werden. Die anderen zehn Prozent (oder weniger) können in ihrer eigenen eindeutigen Konfigurationsdatei verwaltet werden. Zur Laufzeit werden die Dateien übereinander geschichtet, um eine flexible, verwaltbare Konfiguration zu ermöglichen. In einer Entwicklungsumgebung wird myhost.config.xml beispielsweise mit dev.config.xml und base.config.xml zu meiner eindeutigen Konfiguration kombiniert.
Jede Konfigurationsdatei kann dann in der Versionskontrolle verwaltet werden, da sie eindeutige Namen hat. Nur die Basisdateien müssen geändert werden, wenn sich die Basiswerte ändern, und der Unterschied zwischen den Versionen ist leicht zu erkennen. Ein weiterer großer Vorteil besteht darin, dass Änderungen an der Basiskonfigurationsdatei vor der Bereitstellung umfassend getestet werden.