2014-06-12 13 views
5

In UNIX und seinen Derivaten befinden sich Anwendungskonfigurationsdateien unter/etc /, während sie an anderen Stellen auf Windows und anderen Systemen gespeichert sind. Die Philosophie hinter Java lautet: "Schreibe einmal, laufe überall hin" und eine App sollte sich im Idealfall nicht darum kümmern müssen, auf welchem ​​Betriebssystem sie läuft. Aber ich möchte, dass meine Anwendung beim Start eine Konfigurationsdatei lädt, und ich muss einen Pfad angeben. Momentan lade ich verschiedene Dateispeicherorte, um den Namen des Betriebssystems zu deaktivieren, aber das ist nicht so, als wäre es die beste Vorgehensweise für Java. Wie versöhne ich das?Best Practices für die Konfiguration von Konfigurationsdateien

+1

Wenn es tragbar sein sollte, sehe ich nichts falsch daran, es im Anwendungsverzeichnis selbst zu haben. – user432

+0

Java verfügt bereits über eine Präferenz-API, die Betriebssystemunterschiede verarbeitet. http://docs.oracle.com/javase/7/docs/api/java/util/prefs/Preferences.html –

Antwort

1

Wenn ich ein Spiel/eine App mache, lege ich einfach einen Ressourcenordner in den gleichen Pfad wie die App. Im Code wäre das Verzeichnis beispielsweise "res/config.yml". Im selben Ordner wie das Jar, legen Sie den Ressourcenordner "res" an. Sie legen dann die Datei in die Res-Datei. Also sollte die App die Datei bekommen.

0

In unserer Anwendung verwenden wir verschiedene Standorte für die Konfiguration auf jedem Betriebssystem.

Auf Linux

/etc/application

Auf Windows

[Use Selected Install Dir]/conf

Wir kontrollieren, wo die Anwendung aussieht über eine Systemeigenschaft

-Dconf.dir = path

ich nicht unbedingt glaube, es gibt in diesem Fall eine richtige Antwort ist.

0

Ich habe normalerweise Konfigurationsdateien in einem Verzeichnis .<appName> (beachten Sie den führenden Punkt) in der Benutzer-Startseite, die zur Laufzeit über System.getProperty("user.home") gelesen wird. Dies ist der erwartete Standort für Linux-Benutzer, während es sich unter Windows ein wenig exotisch anfühlt (verglichen mit Profilverzeichnissen wie AppData/Local oder AppData/Roaming), auch wenn es eine äußerst beliebte Wahl für plattformübergreifende Tools ist. Wenn Sie das aktuelle Benutzerdomizil verwenden, haben Sie in der Regel keine Probleme mit den Zugriffsrechten für das Dateisystem. Statt einer benutzerdefinierten Eigenschaft wird user.home bevorzugt, da es vom System bereitgestellt wird (und trotzdem überschrieben werden kann)

Ein anderer Ansatz ist die Verwendung des Installationsverzeichnisses, aber dann müssen Sie eine Umgebungsvariable verwenden, die darauf verweist, wie $APP_HOME, weil es im Allgemeinen während der Ausführung der Anwendung nicht abgeleitet werden kann (tatsächlich können Sie das Installationsverzeichnis ziemlich einfach für typische erhalten JAR-Bereitstellungen durch Abspielen von URLs, die vom Haupt-ClassLoader zurückgegeben werden, aber ich betrachte es als Hack und denke, es sollte nicht verwendet werden). Ihre Anwendung kann die Variable mit System.getenv("APP_HOME") lesen, und diese Variable muss von den plattformabhängigen Skripts festgelegt werden, die Sie zum Starten Ihrer Anwendung bereitstellen. Diese Strategie hat den Nachteil, dass der aktuelle Benutzer möglicherweise nicht die Rechte zum Lesen/Schreiben in das angegebene Verzeichnis hat.

Verwandte Themen