Applikations-Konfiguration im Deployment-Deskriptor?

[Tobias]

High,
hab bislang nix zur "best practice" gefunden - deshalb nerv ich euch damit: Packt man in einer J2EE-App applikationsspezifische Konfigurationssachen normalerweise in den Deployment-Deskriptor oder schreibt man dafür eher eine eigene Bean?
Das Problem mit dem Deployment Deskriptor ist, dass man die Konfigurationseinstellungen ja ändern können soll - im DD kann man als Laie aber ne Menge kaputt machen...

mpG
Tobias

 

[foobar]

Applikationsspezifischen Konfigurationsdateien sollten auf jeden Fall in XML vorliegen und mit den anderen Archiven deployed werden, damit man leicht Veränderungen vornehmen kann.

 

[Gast]

Was verstehst Du Denn unter "applikationsspezifischen Konfigurationssachen" ?
Wenn Du Umgebungseinträge meinst, die eine Bean zu Laufzeit lesen
können soll, aber relative einfach änderbar sein soll, benutze "env-entry´s".
Im DD :

<env-entry>
<env-entry-name>meineAenderbareVariable</env-entry-name>
<env-entry-type>java.lang.Integer</env-entry-type>
<env-entry-value>10</env-entry-value>
</env-entry>

Wo immer Du die Variable brauchst:

...
InitialContext ic = new InitialContext();
Integer einIntegerWert = (Integer) ic.lookup("java:comp/env/meineAenderbareVariable");
...
//mach was mit einIntegerWert
int i = einIntegerWert.intValue();
...

 

[Tobias]

Gemeint sind Sachen wie:

- die Hintergrundfarbe
- ...

Das Problem bei solchen Sachen ist, das sie sich durchaus auch nach dem Deployment noch ändern können (geänderte CI etc.). Ich müßte dem Kunden also ein leicht bedienbares Tool zur Verfügung stellen, mit dem er an diesen Einträgen arbeiten könnte. Meine Befürchtung ist einfach, das man im DD zuviel kaputt machen kann - andererseits ist es aber die bequemste Variante. Anscheinend ist es ja auch so, das zumindest Gast es auch so machen würde.

mpG
Tobias

 

[Gast]

Hallo Tobias,

da haben wir uns wohl mißverstanden. Aber gewaltig.
1. Wenn wir von DD (Deployment Descriptor) sprechen, rede/n wir/ich von Java-Enterprise-Beans. Hier geht es um BusinessLogic/ApplicationLogic und meistens auch Datenhaltung(EntityBeans, JDO, Hibernate usw.).
2. Wenn Du Dich also in diese Spähren begeben willst, solltest Du Dich mit verteilten Anwendungen etwas mehr ausseinandersetzen.

Wenn Du also mit Hintergrundfarben o.ä. zu tun hast, bist Du bei der Präsentationsschicht(SwingClients, Html, JSP).
HintergrundFarben sind ein Fall für CSS (bei webbasierten Anwendungen), oder vielleicht PropertieDateien bei SwingClients.

Um also eine konkrete Antwort zu erhalten, beschreibe bitte genau, woran Du also arbeitest.

MFG
Jörg Bellmann (Gast)

 

[Bleiglanz]

HintergrundFarbe?

=> schieb sowas in die Datenbank, mach dir eine EntityBean

Configuration

mit Properties

key (String, von mir aus auch als PK)
val (String)

der ganze Environmentzeugs ist normalerweise Read-Only

 

[Tobias]

Ok, hast ja recht, die Hintergrundfarbe war ein blödes Beispiel, ist auch mehr aus der Not heraus entstanden.

Folgendes Beispiel:

Ich habe ein Programm (EJB), das via Callback verschiedene Algorithmen zur Lösung eines Problems einsetzen kann. Die Namen der Klassen, die den Algorithmus implementieren, sollen in irgendeiner Form von Konfigurations-"System" hinterlegt werden, so dass sie von der Hauptklasse via Reflection instanziiert und benutzt werden können.

(Die Struktur stammt nicht von mir, ich bin auch der Meinung, dass man das besser lösen kann, aber ich darf nicht.) Wo also würdet ihr solche Sachen ablegen?

mpG
Tobias

 

[Bleiglanz]

dann doch als <env-entry>, diese Sachen sollten ja Konstante sein (und sich im Lauf der Zeit nicht ändern)

oder in einem Properties File innerhalb des jars, kannste ganz normal auslesen

 

[Gast]

Hallo Tobias,

nun ja das ist zwar immer noch sehr ungenau ("...irgendeiner Form von Konfigurations-"System" ...) aber ich versuche mal einen evtl. Ansatz aufzuzeigen.

Die verschiedenen Klassen implementieren ein Interface, kann ja
sein:

public MyInterface{
public void loeseProblem();
}

Bleiben wir bei den "env-entry´s":

<env-entry>
<env-entry-name>ersteImplementierung</env-entry-name>
<env-entry-type>java.lang.String</env-entry-name>
<env-entry-value>com.me.impl.ErsteImpl</env-entry-value>
<env-entry>
<env-entry>
<env-entry-name>zweiteImplementierung</env-entry-name>
<env-entry-type>java.lang.String</env-entry-name>
<env-entry-value>com.me.impl.ZweiteImpl</env-entry-value>
<env-entry>

public class KleineFactory{

private static final KleineFactory instance = new KleineFactory();

public static final int ERSTE_IMPL = 1;
public static final int ZWEITE_IMPL = 2;

public static KleineFactory getInstance(){
return instance;
}

public MyInterface getImplementierung(int implType){
case(ERSTE_IMPL):
InitialContext ic = new InitialContext();
String className = (String) ic.lookup("java:comp/env/ersteImplementierung");
return getImpl(className);
break;
case(ZWEITE_IMPL):
InitialContext ic = new InitialContext();
String className = (String) ic.lookup("java:comp/env/zweiteImplementierung");
return getImpl(className);
break;
}

private MyInterface getImpl(String className){
MyInterface result = null;
try{
Class clazz = Class.forName(className);
result = clazz.newInstance();
}catch(Exception e){
//logger.error(e);
}
return result;
}

... jetzt benutzen, wo auch immer

...
...
MyInterface myInterface = KleineFactory.getInstance().getImplementierung(KleineFactory.ERSTE_IMPL);
myInterface.loeseProblem();
...
...

es stehen jetzt immer zwei mögliche Variablen für Klassennamen bereit. Diese können dann auch im DD geändert werden.

Ich hoffe Du kannst diesen Beitrag gebrauchen. Wäre sonst schade um die Zeit, die sich andere machen.

Jörg Bellmann

 

[Gast]

Ich nochmal,

kleiner Nachtrag:

Ich wollte die "KleineFactory" als Singleton implementieren. Leider habe ich erst nach absenden der Antwort gesehen, daß ich den Konstruktor vergessen habe.

Dieser muß "private" sein, also:

private KleineFactory(){
//vielleicht noch ein bisschen Logging
}

einfach in oben beschriebene Klasse einfügen.

"KleineFactory" muß aber nicht als Singleton implementiert werden.

So, das war es dann.

Jörg Bellmann

 

[Tobias]

Naja, das Konfigurations-"System" war ja eben das Problem - deshalb die wenig exakte Formulierung.

Aber danke, dein Beitrag hat mir sehr geholfen! Danke auch an Bleiglanz.

mpG
Tobias