Konfiguration einer Anwendung aus mehreren Dateien

[xhi2018]

Hallo,

ich hab gerade folgendes Problem ???:L und vielleicht kann mir jemand von Euch weiterhelfen.
Das Programm an dem ich arbeite benötigt zwei Konfigurationsdateien:

Die eine Konfigurationsdatei ist ein ini-File.

key=value
key=value
key=value
...

Die andere Konfigurationsdatei ist eine xml-Datei (wird von extern generiert).

Mein Problem ist nun, dass ich keine Idee hab wie ich es am besten hinbekommen könnte, damit ich auf die Konfigurationswerte der beiden Dateien über ein - ich nenne es mal - "Konfigurationsobjekt" zugreifen kann.

Die unterschiedlichsten Konfigurationswerte aus den beiden Dateien werden in den verschiedensten Klassen der Anwendung immer wieder benötigt.

Zudem sollte über dieses eine Konfigurationsobjekt auch noch Werte gespeichert und abgefragt werden können die sich erst zur Laufzeit des Programmes (z.B. das Programmlaufwerk) ergeben.

Ich hoffe ich konnte meine Problem halbwegs verständlich erklären und bin für jede Hilfe sehr dankbar!

 

[The_S]

Was spricht dagegen, einfach ein "Konfigurationsobjekt" zu verwenden, dass sich um beides kümmert? Evtl. für jede Datei ein eigenes Interface ...

 

[faetzminator]

Du kannst ein Singleton oder statische Methoden zur Verfügung stellen. Des weiteren kann man die ini Datei mit Properties auslesen (Properties (Java 2 Platform SE v1.4.2)) und XML am einfachsten mit JDOM (JDOM).

 

[xhi2018]

Hallo,

Du kannst ein Singleton oder statische Methoden zur Verfügung stellen.

Ist ein Singleton für sowas die richtige Wahl ???:L
In den Beispielen und Erklärungen die ich so gefunden habe wurde in keinem der Einsatz eines Singleton für so ein Konfigurationsobjekt erwähnt...

Des weiteren kann man die ini Datei mit Properties auslesen (Properties (Java 2 Platform SE v1.4.2)) und XML am einfachsten mit JDOM (JDOM).

das lesen der Property Datei funktioniert soweit

...
Properties prop = new Properties();
InputStream inputStrm = null;
inputStrm = GeneratorConfig.class.getClassLoader().getResourceAsStream(DEFAULT_PROPERTY);
try {
   prop.load(inputStrm);
} catch (IOException e) {
...

Aber leider hab ich noch keine Vorstellung wie das ganze praktisch aussehen könnte - hat hierzu vielleicht noch jemand einen Tipp oder sowas in der Art selber schon mal realisiert und könnte mir ein Beispiel zeigen ...

Danke nochmal für Eure Hilfe!

 

[faetzminator]

Hallo,
Ist ein Singleton für sowas die richtige Wahl ???:L
In den Beispielen und Erklärungen die ich so gefunden habe wurde in keinem der Einsatz eines Singleton für so ein Konfigurationsobjekt erwähnt...

Per statische Methode oder ein Singleton wird in vielen Frameworks global auf Einstellungen zurückgegriffen, z.B. auch auf properties Dateien oder DBs.

 

[xhi2018]

Hallo,

entspricht dann so was einem Singleton... :bahnhof:

import java.io.IOException;
import java.io.InputStream;
import org.apache.log4j.Logger;
import java.util.Properties;

/**
 */
public class GeneratorConfigSingleton {

   private static final Logger LOGGER = Logger.getLogger(GeneratorConfigSingleton.class); 
   private static final String GENERATOR_DEFAULT = "generator.properties";
   private static Properties generatorConfig = null;
   
   /**
    */
   private GeneratorConfigSingleton() {
      // Singleton
   }

   /**
    * @return Instanz des Singleton
    */
   public static synchronized Properties getInstance() {
      // lazy Initialization...
      if ( null == generatorConfig ) {
         readProperties();
      }
      return generatorConfig;
   }

   /**
    */
   private static void readProperties() {
      generatorConfig = new Properties();
      InputStream inStrm = GeneratorConfigSingleton.class.getClassLoader()
                                   .getResourceAsStream(GENERATOR_DEFAULT);
      try {
         generatorConfig.load(inStrm);
      } catch (IOException e) {
         LOGGER.fatal("IOException beim Zugriff auf die Datei [ " 
                            + GENERATOR_DEFAULT + " ] ", e);
      } catch (IllegalArgumentException e) {
         LOGGER.fatal("IllegalArgumentException beim Lesen der Datei [ " 
                            + GENERATOR_DEFAULT + " ] ", e);
      } finally {
         try {
            inStrm.close();
         } catch (IOException e) {
            LOGGER.warn("IOException beim schliessen der Datei [ " 
                               + GENERATOR_DEFAULT + " ] ", e);
         }
      }
   }
   
}

oder verstehe ich da noch was falsch - bin für Tipps & Verbesserungen sehr dankbar

 

[The_S]

Hallo,

entspricht dann so was einem Singleton... :bahnhof:

ja, ich würde nur die Eager Creation bevorzugen, dann sparst du dir das synchronized.

 

[bygones]

man kann doch mit Properties sowohl das "=" Format laden als auch das XML... also das einladen ist ja schonmal identisch.

zu dem Singleton:
solche Konstrukte sind meiner Ansicht nach immer haesslich:

String value = Configuration.getInstance().get("foobar")

lieber dann

String value = Configuration.getFooBar();

befreit den Aufrufer a) immer dieses getInstance zu schreiben und b) von dem implementierungsdetail wie nun [c]fooBar[/c] als Schluessel in der Datei steht !

 

[xhi2018]

Hallo,

vielen Dank für die Antworten und Tipps

...zu dem Singleton:
solche Konstrukte sind meiner Ansicht nach immer haesslich:

String value = Configuration.getInstance().get("foobar")

lieber dann

String value = Configuration.getFooBar();

befreit den Aufrufer a) immer dieses getInstance zu schreiben und b) von dem implementierungsdetail wie nun [c]fooBar[/c] als Schluessel in der Datei steht !

Das bedeutet dann ich hab in meiner Singleton Klasse eine Haufen an getter-Methoden wie so was hier (Halt für jede Property in meiner property-Datei eine getter-Methode ..?!):

...
/**
*/
public static String getGeneratorVersion() {
   return generatorConfig.getProperty(GENERATOR_VERSION, "upps - no Version");
}
/**
*/
public static String getTargetDir() {
  return generatorConfig.getProperty(TARGET_DIR, "C:\\");
}...

Und als Klassenvariablen in der Singleton Klasse so was:

private static String GENERATOR_VERSION  = "generator.version";
private static String TARGET_DIR = "target.dir";

Kann das nicht ganz schön "hässlich" & unübersichtlich werden ...???:L

 

[bygones]

Kann das nicht ganz schön "hässlich" & unübersichtlich werden ...???:L

was soll daran haesslich sein... eine Klasse mit vielen statischen Methoden - find ich nicht unuebersichtlich.

was ist das gegenstueck ?

in allen Klassen die die Infos von TARGET_DIR haben wollen muss man dann schreiben:

String targetDir = Configuration.getInstance().get("target.dir", "C:\\");

vor allem wenn du noch den default Wert angeben willst. Wenn der Aufrufer nun "taget.dir" schreibt hat er ein Problem, wenn er statt "C:\\" einfach mal "D:\\" schauts auch schon wieder anders aus.

natuerlich kann man dann auch sagen

String targetDir = Configuration.getInstance().get(Configuration.TARGET_DIR, Configuration.DEFAULT_TARGET_DIR);

a) ist das nun schoen
b) ist dann die Configuration klasse schoen

nein.

und dann wird aufeinmal im properties file nicht mehr target.dir sondern targetDir geschrieben... "uch verdammt... wo war das noch ueberall wo target.dir genutzt wird ?" - nene

wenn einzig und allein Configuration bescheid weiss ueber die Struktur der Konfiguration kann sich diese Aendern bzw geandert werden ohne dass es impact auf andere Stellen hat.
Daher musst du dann auch nicht die keys zB als Konstante speichern... wenn dir dass dan besser gefaellt ;-)

Den Gewinn den man durch direkte Zugriffsmethoden erhaelt schlaegt um laengen alles andere meiner meinung nach !

 

[maki]

Den Gewinn den man durch direkte Zugriffsmethoden erhaelt schlaegt um laengen alles andere meiner meinung nach !

Commons Configuration macht das auch so, da werden allerdings die Methoden noch nach Typ unterschieden ([c]getString("name")[/c], etc.), falls man mal etwas anderes als Strings braucht.

 

[xhi2018]

Hallo,

hab leider (noch) ich nicht allzu viel Ahnung von Java im allgemeinen und OO-Programmierung / Design im Besonderen...
Deswegen die vermutlich etwas doofen Fragen - vielen Dank nochmal für Deine Hilfe!

was soll daran haesslich sein... eine Klasse mit vielen statischen Methoden - find ich nicht unübersichtlich.

was ist das gegenstueck ?
....
a) ist das nun schoen
b) ist dann die Configuration klasse schoen
nein.

und dann wird aufeinmal im properties file nicht mehr target.dir sondern targetDir geschrieben... "uch verdammt... wo war das noch ueberall wo target.dir genutzt wird ?" - nene

wenn einzig und allein Configuration bescheid weiss ueber die Struktur der Konfiguration kann sich diese Aendern bzw geandert werden ohne dass es impact auf andere Stellen hat.

ok - hört sich durchaus logisch und nachvollziehbar an ...

Ich hab es jetzt so, dass ich zwei Klassen GeneratorConfig und GeneratorProperties hab.
Einmal die Singleton Klasse, welche die Property-Datei einliest mit den ganzen statischen getter-Methoden:

public class GeneratorConfig {

   private static final Logger LOGGER = Logger.getLogger(GeneratorConfigSingleton.class); 
   private static final String GENERATOR_DEFAULT = "generator.properties";
   private static Properties generatorConfig = null;

   private GeneratorConfig() {
      // Singleton
   }
   public static synchronized Properties getInstance() {
      // lazy Initialization...
      if ( null == generatorConfig ) {
         readProperties();
         dump();
      }
      return generatorConfig;
   }
   public static String getGeneratorVersion() {
      return generatorConfig.getProperty(GeneratorProperties.GENERATOR_VERSION, "no Version");
   }
   public static String getTargetDir() {
      return generatorConfig.getProperty(GeneratorProperties.TARGET_DIR, "C:\\");
   }
...
// und noch viel viel mehr an getter-methoden 
...
   private static void readProperties() {
      generatorConfig = new Properties();
     
      InputStream inDefProp = GeneratorConfig.class.getClassLoader().
                                       getResourceAsStream(GENERATOR_DEFAULT);
      try {
         generatorConfig.load(inDefProp);
      } catch (IOException e) {
         LOGGER.fatal("IOException beim Zugriff auf die Datei [ " 
                            + GENERATOR_DEFAULT+ " ] ", e);
      } catch (IllegalArgumentException e) {
         LOGGER.fatal("IllegalArgumentException beim Lesen der Datei [ " 
                            + GENERATOR_DEFAULT+ " ] ", e);
      } finally {
         try {
            if ( null != inDefProp ) {
               inDefProp.close();
            }
         } catch (IOException e) {
            LOGGER.warn("IOException beim schliessen der Datei [ " 
                                + GENERATOR_DEFAULT+ " ] ", e);
         }
      }
  }
}

und dann noch eine weitere Klasse in der "nur" die gültigen Properties (keys) als Konstanten definiert sind:

public final class GeneratorProperties {
   private GeneratorProperties() {
      // utility class
   }

   protected static final String GENERATOR_VERSION = "generator.version";

   protected static final String TARGET_DIR = "target.dir";
...
// und noch viele viele weitere Konstanten
...         
}

Daher musst du dann auch nicht die keys zB als Konstante speichern... wenn dir dass dan besser gefaellt ;-)

Hm... :bahnhof: wie meinst Du das ???:L
Genau das hab ich ja aktuell - ich hab alle möglichen Properties als Konstanten in der Klasse GeneratorProperties definiert.
Ich könnte mir vorstellen, das dies mit immer mehr Properties und im Laufe der Zeit/im Laufe der Änderungen an dem Programm dann doch mal "hässlich" & unübersichtlich werden könnte - gut ich hab alles an einer Stelle und wenn ich die Konstanten in der Klasse GeneratorProperties ändere kompiliert die Klasse GeneratorConfig nicht mehr. Von dem her gesehen merke ich die impacts recht früh.

Wie schon gesagt, ich hab' bzgl. der Java/OO-Programmierung noch nicht viel Erfahrung und mich würde nur interessieren ob das was ich hier so mache in der Praxis auch so gemacht wird.

Ich hab mir auch einiges über Singletons durchgelesen und immer wieder ist der Hinweis gefallen, dass oftmals in der Praxis durch statische Zugriffe das Prinzip von Singletons umgangen wird.
Wie dieser Hinweis gemeint ist hab ich zwar nicht verstanden - ich denk mir nur. Meine Methoden in der Singleton Klasse sind ja alle statisch ...?! Ist das so vom Design / Verwendung her in Ordnung ?

Vielen Dank nochmal!