Einen meiner Azubis habe ich vor einigen Wochen die Aufgabe gegeben, sein in Java geschriebenes Website-Crawler Tool auf Spring zu portieren. Dabei kam es dann logischerweise zu einigen Fragen und Pitfalls, über die man als Spring-Neuling stolpert.

In diesem Artikel will ich auf die Hürden bei der Entwicklung mit Spring hinweisen, die man als Java- bzw. Spring-Neuling zwangsläufig hat. Anspruch auf Vollständigkeit ist angesichts der Komplexität von Spring natürlich nicht mal annähernd zu erwarten

Warum Spring?

Das Spring Framework besteht aus einer Vielzahl an Klassen, die wiederkehrende Aufgaben bereits implementiert haben und getestet sind. So entfällt z.B. das umständliche Erzeugen der Datenbank-Verbindungen und ähnlicher Sachen.
Spring setzt auf das Prinzip der Dependency Injection. Dahinter versteckt sich grob gesagt die Tatsache, dass Objekte innerhalb des Quellcodes nicht mehr mit dem Schlüsselwort new erzeugt werden, sondern dass die Instanzierung von Objekten durch Spring geschieht. Durch diese Tatsache wird die Abhängigkeit zwischen Klassen reduziert, einzelne Funktionalitäten lassen sich leichter austauschen. Damit einhergehend ist es auch wichtig, dass gegen Interfaces programmiert wird und nicht gegen konkrete Klassen.

Die Beispielapplikation

Ziel soll es sein, dass wir eine einfache Main-Klasse haben, die in Abhängigkeit von der Konfiguration entweder die Klasse StringHandlerBackward oder StringHandlerSecond besitzt. Beide StringHandler-Klassen implementieren das Interface IStringHandler. StringHandlerBackward gibt einen String von hinten nach vorne aus, StringHandlerSecond gibt nur jeden zweiten Buchstaben aus.

Die XML-Konfigurationsdatei I, XML & XSD

Spring setzt auf die Konfiguration durch XML-Dateien. Innerhalb der XML-Datei wird deklarotisch hinterlegt, welche Objekte mit welchen Eigenschaften automatisch bei ihrer Ansprache erzeugt werden. Im folgenden Beispiel wird unsere Spring-Konfiguration in der Datei applicationContext.xml hinterlegt. Die XML-Datei hat folgenden Aufbau:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="

http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-3.0.xsd

http://www.springframework.org/schema/context

http://www.springframework.org/schema/context/spring-context-3.0.xsd">

</beans>

xmlns=”http://www.springframework.org/schema/beans” besagt, dass Standard-Namespace der XML-Datei http://www.springframework.org/schema/beans ist. Innerhalb des Attributs xsi:schemaLocation wird zugewiesen, dass der Namespace http://www.springframework.org/schema/beans innerhalb der XSD-Datei
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd beschrieben ist.
Eine XSD-Datei enthält Informationen darüber, wie eine XML-Datei aufgebaut sein darf (Reihenfolge der Tags/Elemente, welche Elemente benutzt werden dürfen, welche Attribute ein Tag/Element enthalten darf/muss u.s.w.).

Über den Standard-Namespace können wir nun alle Elemente aus der spring-beans-3.0.xsd direkt innerhalb unserer XML-Datei benutzen.

xmlns:context=”http://www.springframework.org/schema/context” besagt, dass wir über das Prefix context Zugriff auf den Namespace
http://www.springframework.org/schema/context haben.

Warum das so ist? Man stelle sich vor, dass beide XSD-Dateien (spring-beans-3.0.xsd und spring-context-3.0.xsd) das Element bean erlauben. Woher soll nun der XML-Parser wissen, welche Definition der bean Elements genutzt werden soll? Soll er die Definition aus
spring-beans-3.0.xsd nutzen oder aus spring-context-3.0.xsd? Mit den Prefix context wird das Problem nun umgangen, da wir über bean auf den Standard-Namespace (xmlns) zugreifen, über context:bean hingegen auf den context-Namespace (xmlns:context).

Unsere Java-Klassen

Zu der Konfigurationsdatei kommen wir gleich wieder, erst einmal müssen wir unsere trivialen Java-Klassen schreiben:

IStringHandler.java

interface IStringHandler {
  /**
  * Wandelt den String der Klasse um und gibt diesen zurück
  * @return String
  */
  public String stringify();
}

StringBase.java

class StringBase {
  private String string;

  public StringBase(String _string) {
    setString(_string);
  }

  public StringBase() {
  }

  public void setString(String _string) {
    string = _string;
  }

  public String getString() {
    return string;
  }

StringHandlerBackward.java

class StringHandlerBackward extends StringBase implements IStringHandler {
  public StringHandlerBackward(String _string) {
    super(_string);
  }

  public StringHandlerBackward() {
  }

  public String stringify() {
    StringBuffer sb = new StringBuffer();
    String ref = getString();

    for (i = (ref.length - 1); i >= 0; i--) {
      sb.append(ref.charAt(i));
    }

    return sb.toString();
  }
}

StringHandlerSecond.java

class StringHandlerSecond extends StringBase implements IStringHandler {
  public StringHandlerSecond(String _string) {
    super(_string);
  }

  public StringHandlerSecond() {
  }

  public String stringify() {
    StringBuffer sb = new StringBuffer();
    String ref = getString();

    for (i = 0, m = ref.length; i <= m; i=i+2) {
      sb.append(ref.charAt(i));
    }

    return sb.toString();
  }
}

Main.java

class Main {
  public static void main(String args[]) {
  }
}

Der ApplicationContext und Resourcen

Spring definiert den so genannten ApplicationContext, der Methoden bereit stellt, um auf die in der XML-Datei hinterlegten Beans zuzugreifen. Für unsere Zwecke soll die Klasse ClasspathXmlApplicationContext dienen. Diese implementiert das Interface ApplicationContext und noch andere Interfaces, die die Arbeit erleichtern. ClasspathXmlApplicationContext ist für die Arbeit mit XML-Konfigurationsdateien innerhalb des Java-Classpath gedacht.

Mit Hilfe von

AbstractXmlApplicationContext ctx = new ClasspathXmlApplicationContext("applicationContext.xml");

definieren wir, dass Spring die Datei applicationContext.xml laden soll. Diese muss sich im Java-Classpath befinden.

Wir können aber auch folgendes machen:

AbstractXmlApplicationContext ctx = new FileSystemXmlApplicationContext("classpath:applicationContext.xml");

FileSystemXmlApplicationContext erbt ebenfalls von AbstractXmlApplicationContext und bietet die Möglichkeit, über Prefixe auf Resource zuzugreifen. Das Prefix classpath führt dazu, dass die Datei innerhalb des Classpathes gesucht wird. Das Prefix file hingegen, weist auf eine Suche im Dateisystem hin. Mehr Infos gibt es in der Resources-Abteilung von Spring.

Über die lokale Variable ctx können wir nun unser Bean laden und den Text ausgeben:

IStringify stringifierBean = (IStringify)ctx.getBean("stringifierBean");
System.out.println(stringifierBean.stringify());

ctx.getBean(“stringifierBean”) sucht nun in der XML-Konfiguration nach einem Bean mit genau diesem Namen und erzeugt es.

Unsere Main-Klasse sieht nun folgendermaßen aus:

class Main {
  public static void main(String args[]) {
    // Neuen ApplicationContext laden. Unsere XML-Konfiguration applicationContext.xml wird dabei im Classpath gesucht
    AbstractXmlApplicationContext ctx = new FileSystemXmlApplicationContext("classpath:applicationContext.xml");
    // getBean("idDesBeans") lädt nun das Bean. getBean() liefert Object zurück, deshalb der Typecast in das korrekte Interface
    IStringify stringifierBean = (IStringify)ctx.getBean("stringifierBean");
    System.out.println(stringifierBean.stringify());
  }
}

Die XML-Konfigurationsdatei II, Beans

Immer noch am Grübeln, woher denn nun das ominöse stringifierBean kommt? Hier folgt die Aufklärung: Jedes Bean, dass wir innerhalb unseres Java-Codes ansprechen wollen, braucht einen Identifier und/oder Namen. Hinter stringifierBean verbirgt sich nun das Bean, dass wir zur Verarbeitung des Strings benutzen. Ein Bean ist nichts weiter als eine Java-Klasse mit optionalen getter- und setter-Methoden und mindestens einem öffentlichen Konstruktor (auf Factories werde ich jetzt nicht weiter eingehen).

Folgenden Code-Schnipsel packen wir nun in das beans-Element unserer XML-Datei:

  <bean id="stringifierBean" name="stringifierBean" class="StringHandlerSecond" />

Wo ist der Unterschied zwischen den Attributen id und name? Spring behandelt unter 3.3.1 Naming Beans das Thema. Kurz gesagt: id benutzen. Jede ID darf genau einmal vergeben werden!

Mit der obigen XML-Deklaration definieren wir, dass Spring beim Aufruf von getBean(“stringifierBean”) eine Instanz der Klasse StringHandlerSecond zurückliefert. Um hingegen eine Instanz der Klasse StringHandlerBackwards zu bekommen, müssen wir anstatt class=”StringHandlerSecond” class=”StringHandlerBackwards” schreiben.

Singletons, Scopes und Prototypen

Standardmäßig verhält sich Spring so, dass von einem Bean genau immer eine Instanz erzeugt. Nicht zwei, nicht 20, nicht 200 sondern genau eine. Jedes Bean ist somit ein Singleton.
Folgender Code macht keinen Sinn:

IStringHandler stringHandler1 = ctx.getBean("stringifierBean");
IStringHandler stringHandler2 = ctx.getBean("stringifierBean");

ctx.getBean(“stringifierBean”) liefert die selbe Instanz zurück, somit ist stringHandler1 und stringHandler2 das selbe Objekt und wir haben doppelten Code.
Manchmal (oder öfter) ist es aber nötig, dass von einer Klasse nicht nur eine Instanz sondern n-Instanzen existieren können. Spring führt deshalb den so genannten Scope ein. Dieser definiert, was beim Zugriff auf das Bean mit getBean(“beanName”) geschieht. Standardmäßig steht der Scope auf singleton. Um mit jeden Aufruf ein neues Objekt der Klasse zu bekommen, muss der Scope auf prototype stehen. Um das zu erreichen, müssen wir unsere Bean-Definition folgendermaßen anpassen:

  <bean id="stringifierBean" name="stringifierBean" class="StringHandlerSecond" scope="prototype"/>

Das Attribut scope mit dem Wert prototype bemerkt? Gut! Genau das sorgt dafür, dass mit jedem Auf ein neues Objekt erzeugt wird.

Was macht denn Spring nun eigentlich beim Aufruf von getBean()?

Spring geht beim Aufruf von ctx.getBean(“stringifierBean”) folgendermaßen vor:

• Existiert das Bean stringifierBean in der Konfiguration?
  Nein: Fehler
  Ja: Weiter geht es
• Hat das Bean einen prototype Scope?
  Ja: Neues Objekt erzeugen
  Nein:: Weiter geht es
• Existiert das Bean stringifierBean im Cache von Spring?
  Ja: Objekt aus dem Cache zurückliefern
  Nein: Neues Objekt erzeugen, im Cache speichern und Referenz auf das Objekt zurückliefern.

Properties und Konstruktor-Argumente

Momentan macht unsere Applikation noch gar nichts, da der String, der umgewandelt werden soll, noch nicht hinterlegt worden ist.
Wir können nun den String auf zwei Arten injizieren:

  <bean id="stringifierBean" name="stringifierBean" class="StringHandlerSecond">
    <property name="string" value="Mein String" />
  </bean>

Dadurch wird das Objekt von Spring erzeugt (es wird der leere Konstruktor benutzt) und dann dann die setter-Methode setString mit dem Wert “Mein String” aufgerufen.
Intern macht Spring eine Art

StringHandlerSecond stringifierBean = new StringHandlerSecond();
stringifierBean.setString("Mein String");
// addToCache(stringifierBean);

  <bean id="stringifierBean" name="stringifierBean" class="StringHandlerSecond">
    <constructor-arg type="java.lang.String" value="Mein String" />
  </bean>

Hiermit wird der Konstruktor aufgerufen, dessen Parameter vom Typ java.lang.String ist.
Auch hier wieder der Pseudo-Code, der innerhalb von Spring aufgerufen wird (ist natürlich alles etwas komplizierter, zum groben Verständnis soll das aber reichen):

StringHandlerSecond stringifierBean = new StringHandlerSecond("Mein String");
// addToCache(stringifierBean);

Man kann natürlich auch beides kombinieren:

  <bean id="stringifierBean" name="stringifierBean" class="StringHandlerSecond">
    <constructor-arg type="java.lang.String" value="Mein String" />
    <property name="string" value="Und dann überschreibe ich den String" />
  </bean>

StringHandlerSecond stringifierBean = new StringHandlerSecond("Mein String");
stringifierBean.setString("Und dann überschreibe ich den String");
// addToCache(stringifierBean);

Man kann auch mit Hilfe des Attributs ref auf andere Beans verweisen. Bei der Verwendung des Attributs ref ist wichtig, dass das zu referenzierende Bean nicht wieder auf das Bean verweist, von dem referenziert wird. Nicht verstanden?

<bean id="A" name="A" class="AKlasse">
  <property name="andereKlasse" value="B" />
</bean>

<bean id="B" name="B" class="BKlasse">
  <property name="andereKlasse" value="A" />
</bean>

Das funktioniert nicht, da wir in eine so genannte zirkuläre Abhängigkeit geraten. A und B hängen gegenseitig von einander ab. Spring weiß nicht, wie er die Klassen zuerst initalisieren soll.

.properties-Dateien, Einstellungen auslagern

Momentan haben wir den Wert für unseren umzuwandelnden String noch fest in die XML-Datei geschrieben. Das ist natürlich möglich, der Endanwender interessiert sich aber eher nicht so für das ganze XML-Geraffel. Deshalb lagern wir die Variablen nun aus. Dazu speichern wir folgenden Code in der Datei stringifier.properties

stringifier.class=StringHandlerSecond # oder StringHandlerBackwards
stringifier.string=Hallo Wald!

und passen unsere applicationContext.xml an:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="

http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-3.0.xsd

http://www.springframework.org/schema/context

http://www.springframework.org/schema/context/spring-context-3.0.xsd">

    <context:property-placeholder location="stringifier.properties"/>

    <bean id="stringifierBean" name="stringifierBean" class="${stringifier.class}">
      <constructor-arg type="java.lang.String" value="${stringifier.value}" />
    </bean>
</beans>

Mit context.property-placeholder definieren wir eine Konfigurationsdatei, in der die zu ersetzenden Werte im Muster ${} stehen.

Das soll erst einmal reichen. Spring umfasst noch viel viel mehr, sei es Annotations, AOP, Unterstützung von Scriptsprachen u.s.w. – Ich kann nur empfehlen, sich die hervorragende Dokumentation durchzulesen. Sie ist meiner Meinung nach eine der besten Dokumentationen, die im Internet zu finden ist.