Die Anwendung kann auf vielfältige Weise konfiguriert werden, die genaue Bedeutung und Auswahl der Einstellungen ist anwendungsspezifisch. Die generellen Mechanismen zur Feststellung der aktiven Konfiguration sind davon jedoch unabhängig. Dieser Abschnitt beschreibt, wie diese Mechanismen funktionieren.

Einstellungen sind individuelle Informationen, welche vom Benutzer angegeben oder verändert werden können, um damit das Verhalten der Anwendung für gewisse Operationen oder Arbeitsbereiche zu beeinflussen. Jede Anwendung hat ihren ihr eigenen Satz von unterstützten Einstellungen, jedoch stehen davon einige bei vielen Anwendungen zur Verfügung, da sie von einer sehr allgemeinen Natur sind (wie z.B. die Konfiguration der Logging-Moglichkeiten).

Um eine komfortable Benutzung zu gewährleisten, können diese Einstellungen in eine Datei gespeichert werden und bei nachfolgenden Ausführungen der Anwendung als Vorgabeeinstellungen verwendet werden. Um grösstmögliche Flexibilität für einen grossen Bereich an Szenarien zu gewährleisten, können solche Konfigurationsdateien an mehreren verschiedenen Stellen auf Disk gespeichert vorliegen. Und als weitere Bequemlichkeit können alle Einstellungen auf der Kommandozeile überschrieben werden, wenn die Anwendung gestartet wird.

Beim Starten der Anwendung werden alle unterstützten Orte untersucht und etwelche gefundenen Konfigurationsdateien werden geladen und in den Satz der aktiven Einstellungen hineinkombiniert. Nachdem alle Einstellungen geladen und kombiniert wurden, fährt das Starten der Anwendung fort.

Dies ist die Reihenfolge, woher Einstellungen geladen werden:

Damit eine Einstellung von den system properties geladen werden kann, muss das entsprechende property bereits gesetzt sein. So wird es unter Umständen notwendig, ein property via die Option -D beim Aufruf der Java Virtual Machine über die Kommandozeile anzugeben. Es ist jedoch auch möglich, system properties über das Laden von Einstellungen selbst zu modifizieren. Dazu muss ein property in der geladenen Datei mit dem Präfix System.setProperty. versehen sein. Um also z.B. das system property settings.dir via geladener Einstellungsdatei für die weitere Verwendung zu setzen, muss es als System.setProperty.settings.dir in dieser Datei aufgeführt sein. Dieser Mechanismus sollte nur verwendet werden, wenn genau bekannt ist, was die Konsequenzen sind, denn es ist einfach möglich, dadurch den Ladeprozess von wichtigen system properties nachhaltig in nicht unterstützter Weise negativ zu beeinflussen.

Der Mechanismus zum Setzen von System Properties kann zum Beispiel sehr nützlich sein, um die Dateipfade der Kerberos JAAS Login-Konfiguration auf bequeme Weise zu setzen:

Während dem Laden der verschiedenen Dateien überschreibt jeder Schritt die Einstellungen des/der vorangegangenen Schritte(s). Daraus resultiert, dass die Kommandozeile fast die höchste Priorität erhält, da sie zuletzt interpretiert wird. Nur die Einstellungsdatei, welche in den Einstellungen selbst angegeben ist, hat noch höhere Priorität. Dies kann auch als eine job-definitions Datei verstanden werden. Diese ist auch die einzige Datei, welche einen Fehler auslöst, falls sie nicht gefunden wird.

AppName steht für den Namen der Basisklasse einer Anwendung. Wenn also die Hauptklasse einer Anwendung foo.bar.MyApp.java benannt ist, so wird AppName als MyApp interpretiert. Somit sollte die gesuchte Einstellungsdatei MyApp.properties benannt sein. Bei BoarderZone Anwendungen ist im Normalfall die zugehörige JAR Datei mit MyApp.jar benannt.

Ist ein system property (z.B. AppName.home) nicht verfügbar, so wird der entsprechende Schritt ausgelassen. Wird eine der Einstellungsdateien an den unterstützten Orten nicht gefunden, so spielt dies keine Rolle.

Die system properties AppName.home und settings.dir sind dafür gedacht, um maschinenweit Einstellungen konfigurieren zu können (z.B. lokale Pfade), welche für alle Anwender auf dieser Maschine gültig sein sollen. Dabei sollte AppName.home auf das Installationsverzeichnis der Anwendung zeigen und settings.dir auf ein Verzeichnis mit systemweiten Einstellungen (z.B. das /etc Verzeichnis auf Unix Systemen).

settings.dir ist per Vorgabe auf ${user.home}/.boarderzone eingestellt. app.home ist auf das Verzeichnis gesetzt, welches die Haupt-JAR-Datei der Anwendung enthält.

Die system properties user.home und user.dir sind standard Java system properties und repräsentieren das Heimverzeichnis des Benutzers (für benutzerspezifische Einstellungen), respektive das aktuelle Arbeitsverzeichnis des Benutzers (für aufrufspezifische Einstellungen).

Unterstützt eine Anwendung das Speichern ihrer eigenen Einstellungen (entweder automatisch oder explizit durch den Benutzer), so wird sie dies nur an einen einzigen Ort hin tun. Wo dieser Ort liegt, kann mit der Einstellung config-save festgelegt werden. Standardmässig ist dies auf ${settings.dir} gesetzt, was normalerweise auf ein Unterverzeichnis des Heimverzeichnis vom Benutzer zeigt. Damit ist sichergestellt, dass jeder Benutzer über ausreichende Privilegien verfügt, die Einstellungsdatei zu beschreiben. Dies muss allenfalls angepasst werden, wenn settings.dir auf ein systemweites Verzeichnis zeigt, in welchem normale Benutzer keine Schreibrechte haben.

Einige der Einstellungen können Pfade ins Dateisystem enthalten. Damit die gleiche Einstellungsdatei von verschiedenen Benutzern genutzt werden kann (als systemweite Vorgabe), sollten solche Dateien keine absoluten Pfade aufweisen für Einstellungen, welche jedem Benutzer individuell zugeordnet sein sollten. Um dies zu unterstützen ist es erlaubt, Bereiche solcher Dateisystempfade mit system propeties oder Variablen zu repräsentieren. Z.B. kann die Einstellung dialog-properties mit ihrem Vorgabewert ${settings.dir}/${app.name}Dialog.properties von allen Benutzern verwendet werden, und wird für unterschiedliche Benutzer zu verschiedenen Dateien aufgelöst (z.B. zu /home/users/jdo/.boarderzone/MyAppDialog.properties für einen Benutzer mit Namen jdo auf einer Unix Maschine).

Ein kleiner Satz von Variablen wird von der Anwendung selbst zur Verfügung gestellt, z.B. enthält app.name den Basisnamen der Anwendung. Wenn zu Konfigurationszwecken mehr Variablen benötigt werden, so können diese durch eine in der Einstellung variables spezifizierte Datei geladen werden. Dies ist entweder eine standard Java properties Datei oder eine XML Datei, welche dem spezifischen XML schema genügt. Die XML Version erlaubt die ausgeklügelte Strukturierung mittels mehrerer XML Dateien, welche zu verschiedenen Kombinationen von Variablen aus unterschiedlichen Quellen zusammengeführt werden können. Für weitergehende Informationen siehe Definition und Verwendung von Variablen.

Mit all diesen Möglichkeiten, woher Einstellungen geladen werden können, ist es manchmal schwierig herauszufinden, was nun der effektive Wert einer Einstellung ist. Um Problemen auf die Spur zu kommen, erlaubt die Einstellung config-dump die Ausgabe aller Einstellungen mit ihren zugehörigen Werten auf die Konsole, nachdem die Konfigruation komplett geladen wurde, jedoch bevor die Anwendung mit dem Starten fortfährt.