Glassfish: Properties zur Laufzeit... wohin?

[musiKk]

Hallo,

ich habe hier einen Glassfish v2 und gerade noch so ein kleines Verständnisproblem. Und zwar weiß ich nicht, wo ich Einstellungen einer Application hinlegen kann, die ich auch zur Laufzeit ändern kann, also ohne die Application neu zu "deployen". Ein Beispiel ist z. B.: Empfänger für Emails. Über die Mail-API versende ich Emails an verschiedene Leute und möchte in der Lage sein, die Empfänger der Mails dynamisch auszulesen. Auch der Inhalt der Mails soll eigentlich nicht fest sein. Den Absender legt man ja über die "JavaMail Sessions" im Web-Interface an.

Außerdem käme das ganz gelegen zur Trennung von Entwicklungs- und Produktivsystemen. Teilweise gibt es da Unterschiede.

Bei Google habe ich nichts Gescheites gefunden. Für Hinweise wäre ich dankbar.
mK

 

[maki]

[c]web.xml[/c] wäre eine Möglichkeit, dann muss die App zwar nicht re-deployed aber dafür neu gestartet werden.
DB wäre eine andere Möglichkeit.

 

[musiKk]

Über die [c]web.xml[/c] regle ich das im Moment teilweise schon. Der Nachteil (?) wäre wohl dabei, dass das Deployen anders (komplizierter) ablaufen müsste. Im Moment erzeuge ich einfach nur ein EAR mit der kompletten Application und die [c]web.xml[/c] ist dort in einem WAR. Ich nehme an, beim Deploy wird die angepasste [c]web.xml[/c] auf dem Server wieder überschrieben.

An die Datenbank dachte ich auch schon, aber für banale Dinge wie Konfigurationen, erscheint mir das irgendwie "ungewöhnlich". Da stehen z. B. auch Pfade drin, weil es Servlets für Uploads gibt etc.

 

[maki]

Die meisten Server haben doch eine Konfig. Konsole für die web.xml, wieso solltest du da neu deployen müssen?
Oder sprichst du davon wenn man etwas neu-deployed werden soll?

An die Datenbank dachte ich auch schon, aber für banale Dinge wie Konfigurationen, erscheint mir das irgendwie "ungewöhnlich". Da stehen z. B. auch Pfade drin, weil es Servlets für Uploads gibt etc.

Ist gar nicht so ungewöhnlich
Eine Properties Datei ist auch nur eine DB, wenn auch eine sehr sehr primitive...
Klar ist der Aufwand größer, dafür gibt es eben mehr flexibilität, wichtig ist eben was man braucht

 

[musiKk]

Oder sprichst du davon wenn man etwas neu-deployed werden soll?

Ja, genau. Wenn Änderungen in der lokalen Entwicklungsumgebung vorgenommen und getestet wurden und ins Produktivsystem sollen. Da das alles erstmal nur intern ist, kann das noch etwas häufiger vorkommen.

Ist gar nicht so ungewöhnlich
Eine Properties Datei ist auch nur eine DB, wenn auch eine sehr sehr primitive...
Klar ist der Aufwand größer, dafür gibt es eben mehr flexibilität, wichtig ist eben was man braucht

Ok. Wenn "man das so macht". Damit wäre immerhin auch die Zukunft bzgl. möglichem Clustering gesichert.
Ich lass es erstmal noch als unbeantwortet stehen, falls noch jemand was zu erzählen hat.

 

[FArt]

Die Konfiguration über Properties ist (wenn der AS keine Möglichkeiten wie Resource-Adapter oder PropertiesService bietet) nicht unbedingt sinnvoll. Auch das Handling (umkonfigurieren zur Laufzeit) ist u.U. nicht trivial (ok, in deinem Fall vermutlich schon).
Einfache Lösung: benutze ein EJB als Provider für deine Adressen. Dieses kannst du über die Deploymentdeskriptoren konfigurieren und einfach redeployen => keine Propertiesdatei nötig. Ok, das EJB kann auch eine Propertiesdatei über den Classloader lesen und dann die Adressen bereitstellen ;-)

 

[musiKk]

Ok, danke für den Input. Ich habe erstmal den Vorschlag von maki umgesetzt und verwende eine lokale Derby-DB. Damit ist alles sehr gut konfigurierbar und ausgewählte Einstellungen können einfach und dauerhaft auch über die Anwendung selbst gesteuert werden, z. B. können in diesem konkreten Fall autorisierte Personen sich selbst zu diversen Mailverteilern hinzufügen.