beste Ort, um properties-Datei in IBM websphere 8.5?

In unsere bestehenden Anwendung-Eigenschaften-Datei eingebettet ist in eine jar-Datei ,wir beschlossen, sich zu bewegen properties-Datei außerhalb von Ohr(Anwendung) , was ist der beste Ort, um properties-Datei in IBM websphere 8.5 ? so, dass ich abrufen kann, Weg WAR die Environment-Variablen und die Datei sollte vorhanden sein, um alle Knoten in einem cluster ..

InformationsquelleAutor invariant | 2014-05-23

  1. 0

    Können Sie die classloader Verzeichnisse. Ich würde verwenden Sie die directory-Klassen (Sie müssen möglicherweise erstellen) unter $WEBSPHERE_HOME/AppServer/Klassen-and-drop Ihre Eigenschaften gibt. Sollten Sie als in der Lage sein, Sie zu finden Ihre Anwendungen /Servern.

    Überprüfen Sie die Class loader-Seite.

    Möchten Sie vielleicht Lesen Sie meine Antwort für Argumente, warum der Platzierung der Elemente in WAS_HOME/classes wird abgeraten.
    Ich bin nicht einverstanden mit deinen Argumenten in diesem Fall. Wenn er noch Fragen, wie externalisieren Eigenschaften für eine bestimmte Anwendung, die ich verwendet hätte freigegebene Bibliotheken, als Sie erwähnten in Ihrer Antwort. Er war aber sehr spezifische Fragen, eine option, um die verfügbaren Eigenschaften auf allen Knoten im cluster.
    Immer noch nicht helfen. Für horizontales clustering, müssten Sie dies auf jeden physikalischen Knoten sowieso. Der AppServer/Klassen Ansatz ist es nicht, sparen Sie sich Arbeit; es führt mehr Einschränkungen als Vorteile.
    Ich denke immer noch, es ist viel einfacher, praktischer, weniger anfällig für menschliche Fehler und besser, in diesem speziellen Fall(für alle Server in einem cluster), als dass Sie zum konfigurieren der freigegebenen Bibliotheken, die in allen Anwendungen. Auch die shared library die genau das gleiche problem in der horizontalen clutering(Sie würden zu tun haben, die in allen physischen Knoten + - Anwendungen).

    InformationsquelleAutor groo

  2. 8

    Nur meine 2 Cent in der Diskussion.

    Für die schnelle und einfache Lösung, die ich ' D setzen die property-Datei nicht auf der WAS_HOME/Klassen, sondern die PROFILE_ROOT/Eigenschaften - dieser Ordner im classpath, und es wird benutzt, um Eigenschaften zu speichern sowieso. Der Vorteil der über /- Klassen ist, dass bezieht sich auf das Profil, so, wenn Sie verschiedene profile, beispielsweise für test-und integration Sie können über verschiedene Einstellungen verfügen.

    Und für 'Reine' WebSphere-Lösung, die es ermöglichen würden, das verwalten von Eigenschaften über die Konsole könnten Sie Auschecken der Ressource Umwelt-Anbieter (es ist aber ziemlich lang, kompliziert die Lösung):
    http://www.ibm.com/developerworks/websphere/library/techarticles/0611_totapally/0611_totapally.html

    guter Punkt +1 für deine Antwort!
    Ich habe eine neue property-Datei, in der PROFILE_ROOT/Eigenschaften Verzeichnis, aber wenn meine Anwendung sucht nach der Datei, erhalte ich eine FileNotFound exception. Auf der anderen Seite, die Anwendung finden können vorhandene property-Dateien. Muss ich irgendeine Handlung vorzunehmen, die für die neue Datei erkannt zu werden?
    Verwenden Sie getResourceAsStream() Methode, um input-stream? Wie werden Sie versuchen zu laden, Eigenschaften?
    Ich lade die properties-Datei mit FileInputStream.
    Das ist der Grund :-). Weil, der Ordner ist nicht auf das 'Datei-Pfad' aber auf classpath. Ersetzen Sie Ihre Methode mit getResourceAsStream() von ServletContext oder ClassLoader je nach Ihrem Bedarf.

    InformationsquelleAutor Gas

  3. 7

    Im Gegensatz zu den (derzeit) akzeptierte Antwort, ich argumentieren, dass das alles unter WAS_HOME/classes ist ein entmutigen die Praxis. Dieses Verzeichnis wird oft von IBM auf Platz Klassen/JAR-Dateien, die als "intern" WAR, und verwandten Produkten (zum Beispiel bestimmte Versionen von WebSphere Portal-Ort-JAR-Dateien in diesem Verzeichnis).

    Auch, Platzierung der Elemente in WAS_HOME/classes macht die Elemente stehen alle Anwendungen läuft auf WAR aller profile erstellt aus dieser WURDE die installation. Sie können nicht ändern, das Verhalten; so WAR konzipiert ist. Das ist ein weiterer Grund zu dem Schluss, dass WAS_HOME/classes vorbehalten sein sollte WAR für den internen Gebrauch.

    Dieses argument kann verallgemeinert werden, um praktisch alle Lage unter WAS_HOME: Benutzer-Dateien (Dateien, die nicht vom software-Anbieter) sollte sich nicht an Orten, verwaltet durch das Produkt des installer/uninstaller. Die WAS_HOME Hierarchie verwaltet von IBM Installation Manager (oder das WAR der Installer, je nach version WAR in Frage). Ich würde nicht alle meine Dateien da.

    Nun, zurück zu deiner Frage. Wenn Sie müssen Ihre property-Dateien "lose" (nicht im Lieferumfang enthalten, mit einem bestimmten OHR), Ihre beste Wette ist, um Folgendes zu tun:

    1. Erstellen Sie ein Verzeichnis außerhalb der WAR-Verzeichnisstruktur und legen Sie Ihre Dateien dort.
    2. WAR, erstellen Sie eine Shared-Library-definition.
    3. Fügen Sie das Verzeichnis, das Sie erstellt haben, auf den gemeinsam genutzten Bibliothek.

    4. Befestigen Sie die gemeinsam genutzte Bibliothek, um entweder die server oder die Anwendung(en) möchten Sie, dass Ihre property-Dateien zur Verfügung:

      • Befestigen Sie die Freigegebene Bibliothek auf den server, erstellen Sie eine neue Classloader-element auf dem server und fügen Sie die gemeinsame Bibliothek.
      • Zu befestigen, die gemeinsam genutzte Bibliothek, um die Anwendung, führen Sie die Befestigung durch die Bearbeitung der EAR-Eigenschaften in der Administrationskonsole oder über skriptgesteuerte Bereitstellung Parameter.
    Downvoter: darauf zu erklären, was falsch ist mit meiner Antwort?
    Hallo, tut mir Leid. Ich wusste nicht erklären, weil ich war am Handy zu dieser Zeit. Ich downvoted Ihre Antwort für ein paar Gründe.
    Ich downvoted Ihre Antwort für ein paar Gründe. 1) Er war sehr spezifisch auf seine Frage, eine Lösung, die verfügbar sein sollten, um alle Knoten in einem cluster. 2) Er hat nicht erwähnt nichts über portal oder andere Produkte, um Ihren Punkt auf dieses Verzeichnis verwendet werden, die durch andere Produkte ist nur worring über Dinge, die möglicherweise nie passieren(die meisten Fälle). 3) Die shared-library-Lösung ist sehr viel komplexer und Irrtümer in diesem Fall(es gilt für sicher, wenn Sie wollen einfach nur eine einzige app. zum Zugriff auf die Eigenschaften anstelle der vollständigen cluster).
    Ich respektiere Ihre Art von Ansatz, aber ich könnte sagen, ich bin die Art von Kerl, der begünstigt die Einfachheit über versucht, sein völlig konform und perfekte Lösungen. aka - ich bevorzuge einfache Bedienung und übersichtlichkeit der Codierung über die Leistung, bis der Punkt Leistung bacames ein Problem.
    vielen Dank für deine Antwort , wenn putting im classes Ordner ist das problem nur bei portal server ..,ich fühle mich immer noch aktuelle akzeptierte Antwort ist einfach als shared-libraries, wie ich bin nicht mit jedem portal server..

    InformationsquelleAutor Isaac

  4. 1

    versuchen, diese

    1. Erstellen Sie ein Verzeichnis (Speicherort Ihrer Wahl), um zu halten die Eigenschaften-Datei.
    2. Fügen Sie das Verzeichnis, in dem WebSphere-CLASSPATH.
    3. Laden der properties-Datei aus dem CLASSPATH.

    InformationsquelleAutor DwB

  5. 1

    andere Lösung, die ich verwende, ist das hinzufügen einer URL-Ressource-Referenz zu Ihrer Anwendung web.xml. Zum Beispiel "url " Eigenschaften".

    Dann definieren Sie die URLs, die in Websphere, mithilfe der admin-Konsole, zeigen Sie auf "file:///dev.Eigenschaften" oder "file:///test.Eigenschaften", zum Beispiel.

    Dann bei der Bereitstellung, Zuordnung der URL-Verweis auf die entsprechende websphere-URL-definition.

    Nun, dein code kann nur tun, einen jndi-lookup der URL.

    Dies hat den Vorteil, dass Sie die Bereitstellung einer einzigen Codebasis, und anpassen, bei der Bereitstellung auf unterschiedlichen URLs.

    InformationsquelleAutor Greycon

  6. 0

    Datenbank ist der beste Ort, um die Eigenschaften, wenn die Eigenschaft-Werte sind nicht spezifisch auf einen Knoten des Clusters oder der Wert der Eigenschaft ist ein Passwort. Für Eigenschaften wie Passwörter würde ich vorschlagen, legen Sie die Eigenschaft Werte als jndi-Eigenschaften in der WAR. Verwenden commons-Konfiguration zu Lesen, sowohl aus den Quellen. Ein .property-Datei in Ihre Codebasis, überschreiben die Werte aus beiden db-und jndi. So können Ihre Entwickler überschreiben, die db/jndi-Werte in der Entwicklung.

    InformationsquelleAutor user3669895

Schreibe einen Kommentar