ich hätte da mal eine Spezial-Frage zu den Property-Files.
Wie das mit dem Erstellen und Auslesen von Properties funktioniert, habe ich im Groben drauf, klappt auch problemlos.
Auch Platzhalter für Variablen (z.B. Jahreszahl in Dateinamen) bekomme ich hin.
Nun will ich aber etwas anderes, und zwar würde ich gerne eine Variable mit dem Wert aus einer anderen Variable aus dem selben Property-File
füttern. Dazu möchte ich allerdings nicht ins Coding eingreifen, das wäre zuviel des Guten.
Es wäre lediglich eine technische Spielerei, um
a) meine Properties einfacher auf unterschiedliche Modi umschalten zu können
b) die Properties zusammenstehen zu lassen, die fachlich zusammen gehören.
Hier geht es um die Variable “BackendSystemHost”, die je nach Modus unterschiedlich gesetzt wird.
Das Beispiel oben mit ${HOST} funktioniert nicht. Hat jemand eine Idee, ob es da überhaupt eine Möglichkeit gibt?
Falls nicht: Bitte nichts basteln - ich will mir keine Lösung ausprogrammieren (könnte ich, will ich aber nicht),
sondern nur meine Properties übersichtlicher “zusammenstellen”…
Mit der normalen Properties-Funktionaliät gibt es keine Variable-Expansion. Properties sind einfach key-Values mit Strings. Also entweder selbst bauen oder ein Framework einbinden, das einen dabei unterstützt. Z.B. Apache commons-configuration . Dort heißt das Feature Variable_Interpolation.
‘bitte nicht basteln’ ist aber auch arg eng gesehen,
was wäre hier viel mehr nötig als eine zentrale Methode für Abfragen (sowieso angebracht),
und dort dann ein if-Test auf $ und (evtl. rekursive) Abfrage des referenzierten Keys,
kaum 5 Zeilen
wenn man noch Fehlermeldungen bei fehlenden Referenz-Keys will usw. dann kommt nach und nach weiteres dazu,
aber was ist die Alternative, Hoffen dass irgend ein Framework es genau so richtig macht wie persönlich gewünscht?
Sieht eher aus wie etwas, das man normalerweise mit ant tasks oder maven profiles macht?
Du wirst doch nicht eine Bibliothek (wie die vorgeschlagene apache.commons.configuration) einbinden, nur damit du verschiedene Ausführungs-, Test- oder Entwicklungsszenarien realisieren kannst?
Vielen Dank für die Info. Ich hatte es mir fast schon gedacht, da ich schon eine Weile sowohl im Forum als auch sonstwo im www
gesucht hatte, ohne fündig zu werden.
Trotzdem wollte ich es nicht unversucht lassen, die Super-Profis zu fragen, hätte ja klappen können.
An dieser Stelle mal ein Lob an euch: wenn man das “alte” Forum mitzählt, bin ich seit 2009 Mitglied eurer Community. Dies
ist allerdings erst der 4. Post mit einer Frage von mir, denn bisher konnte ich mir sonst immer mit fundierten Antworten von
euch auf ältere Anfragen behelfen - die SuFu macht’s möglich!
Ich finde euch klasse!
Diese Lösung ist ziemlich cool; bisher frage ich den Modus immer umständlich mit if/else ab, um entsprechende Properties zu verwenden.
Das werde ich gleich mal ausprobieren, dankeschön!
mit p.get(env+".host"); statt p.get(String.format("%s.host",env)) wärs sogar noch leserlicher ,
falls nicht mehr Spezialitäten dazukommen ist in einem abgeschlossenene Bereich doch die einfache Variante zu bevorzugen
wenn nicht gar noch öfter, statt vorname + " "+nachname auch String.format("%s %s",vorname, nachname)?
[QUOTE=Timothy_Truckle;102246]bei mir sieht sowas so aus: bye
[/QUOTE]
Hmm… geht bei kleineren Sachen bestimmt gut, aber wenn man die Konfig der PROD Umgebung in den Sources verwaltet, hat das Nachteile
Konfiguration sollte immer extern sein. zB. als eigenes Artifakt, dann muss man nicht spezifisch pro Environment bauen, und muss auch nicht das komplette Projekt neu releasen nur weil sich im PROD Environment etwas geaendert hat.
Grundsaetzlich finde ich es nie gut wenn eine Anwednung „weiss“ in welchen Environment sie laeuft, agnostisch ist auf Dauer einfacher.
Vor allem eliminiert das eine völlig überflüssige Fehlerquelle („ach, das ist jetzt im Produktivsystem gelaufen? Ich habe ganz vergessen, meine Property-Datei nochmal zu editieren. Verdammt. Ich hol schon mal das Fluchtfahrzeug…“)
Das kann doch jede IDE mit verschiedenen RUN-Konfigurationen, oder ein paar simple ant-tasks zum anklicken oder oder oder.
Properties sind doch externe einzelne Dateien, jederzeit ohne Release austauschbar usw., wieviel externer geht es denn noch?
was weiß die Anwendung hier mehr als in anderen? entweder die Datei ist da oder auch nicht, warum sollte sie zwingend zum Source gehören?
Source ist nur das Programm, aber egal ob ausgeliefert oder lokal beim Entwickler, irgendwann müssen Zugangsdaten dazukommen,
und wenn man aber lokal umschalten will braucht man eben mehrere Datensätze,
wäre umständlich wenn das Programm nur genau einen Ort und genau eine feste Struktur erwartet, dann muss man im Dateisystem austauschen,
besser die Properties-Datei etwas optionaler aufbauen so dass Änderungen dort reichen,
edit: eigene IDE-Runs wären leicht besser, richtig, da kann man maximal den Fehler machen den falschen Run gestartet zu haben,
die ‘selected_environment’ könnte dort ja der Parameter sein, restliche evtl. viele Daten zum einfachen edit weiterhin in Datei
Meist werden sie ins Artifakt gebundelt, damit sind sie nicht mehr extern
[quote=Bleiglanz;102330]Vor allem eliminiert das eine völlig überflüssige Fehlerquelle („ach, das ist jetzt im Produktivsystem gelaufen? Ich habe ganz vergessen, meine Property-Datei nochmal zu editieren. Verdammt. Ich hol schon mal das Fluchtfahrzeug…“)
[/quote]
In der aktuellen Firma hat man ein sehr komplexes System Konfig geschaffen das keiner mehr versteht, man muss die laufende Anwendung abfragen (JSP seite) um zu wissen was eigentlich wirklich verwendet wird, falls sie startet…
Dazu kommt dass jeder Entwickler seine Konfig comitted, alles in allem keine Gute Sache, aber das ist schon extrem…
,
