• Download the latest flash utility otherwise you will receive the message Invalid flashing API version (1)
• Download 2008 Hacker Edition
• execute on command line

  sudo  ./flasher-3.0-static -F SU-18_2008HACKER_4.2007.50-6_PR_F5_MR0_ARM.bin -f
  

  and wait.

• If you receive the error message Error claiming USB interface: Device or resource busy, run

  sudo modprobe -r cdc_phonet
  

  in another shell

• Plug-in the USB cable from your PC to the Nokia 770
• Power on the Nokia 770 (in my case power cable must be plugged in) while holding down the home button.
• flasher tool will show update status

ssh -t USER,PROJECT@shell.sourceforge.net create
# bzw.
ssh USER@shell.sourceforge.net

auf dem sf.net-Server einloggen.

Mit den folgenden Kommandos werden nun alle Git-Dateien des Projekt-Verzeichnisses gelöscht und das Repository neu initalisiert.

cd /home/scm_git/P/PR/PROJECT
rm -Rf PROJECT/*
mkdir PROJECT
git --git-dir=PROJECT/ init --shared=all
vim PROJECT/description

Meine Methoden sahen in etwa so aus:

public void methodeA(User _a, boolean _b);

public void methodeB(AnderesDomaenenObjekt _b, User _a);

public void methodeB(User _a, User _b);

Leider gibt es momentan noch keine Möglichkeit, einen entsprechenden Pointcut zu definieren, dem die Reihenfolge der Parameter egal ist.

Der Pointcut

	@Before(value = "execution (* de.mypackage.service..*.*(.., de.mypackage.domain.User, ..)) && args(*, _user, *")

funktioniert so nämlich nicht.
Um das Problem momentan zu umschiffen, muss man einen generischen Pointcut definieren, der die Parameter der Methode und die übergebenen Objekte überprüft.
Folgender Code überprüft alle übergebenen Parameter einer Methode und beachtet auch die angehängten Annotations an den jeweiligen Parameter.

@Aspect
@Component
public class ParameterValidAspect
{
	@SuppressWarnings("unchecked")
	@Before(value = "execution (* de.mypackage.service..*.*(..))")
	@Order(AspectOrder.FIRST)
	public void parameterNullCheck(JoinPoint pjp) throws SecurityException,
			NoSuchMethodException
	{
		MethodSignature methodSignature = (MethodSignature) pjp.getSignature();
		String methodName = pjp.getStaticPart().getSignature().getName();
		Class<?>[] paramTypes = methodSignature.getParameterTypes();
		Annotation[][] annotationsByMethod = ((CodeSignature) pjp.getStaticPart()
				.getSignature()).getDeclaringType()
				.getMethod(methodName, paramTypes).getParameterAnnotations();
		Object[] methodArguments = pjp.getArgs();
		Object instance = null;

		for (int i = 0, m = paramTypes.length; i < m; i++)
		{
			instance = methodArguments[i];

			if (instance == null)
			{
				try
				{
					instance = paramTypes[i].newInstance();
				}
				catch (Exception e)
				{
				        // Instanzierungs-Exceptions handeln...
                                }
			}

			if (annotationsByMethod[i].length > 0)
				{
					for (Annotation annotation : annotationsByMethod[i])
					{
						// Annotation behandeln
					}
				}
			}

			if (methodArguments[i] == null)
			{
                                // ParameterNullException handelt dann den jeweiligen Objekttyp
				throw new ParameterNullException(instance);
			}
		}
	}
}

Noch ein allgemeiner Hinweise zur Benutzung von AspectJ in Zusammenhang mit dem Spring Framework: Werden Aspekte über die Annotation @Aspect beschrieben, muss der Aspekt auch mit @Component annotiert werden, damit sie per Auto-Discovery erkannt werden. Benutzt man @Component nicht, muss in der Spring-XML-Konfiguration der Aspekt instanziert werden!

<?xml version="1.0" encoding="UTF-8"?>
<project-modules id="moduleCoreId" project-version="1.5.0">
    <wb-module deploy-name="YourProject">
        <wb-resource deploy-path="/" source-path="/src/main/webapp"/>
	<wb-resource deploy-path="/WEB-INF" source-path="/src/main/resources"/>
        <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/java"/>
        <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/test/java"/>
        <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/test/resources"/>
        <property name="context-root" value="YourProject"/>
        <property name="java-output-path" value="/YourProject/target/classes"/>
    </wb-module>
</project-modules>

Nach dem nächsten Start von Eclipse bekam ich nun folgenden, nichts-sagenden Fehler vom Eclipse-JPA-Plugin: No persistence.xml file found in project.. Pustekuchen, denn unter src/main/resources/META-INF/persistence.xml war die Datei zu finden und auch im Classpath so eingerichtet. Nach einigem hin und her probieren habe ich dann die (absolut bescheuerte) Lösung für das Problem gefunden.

Der Inhalt des ressource-Ordner muss nach /WEB-INF/classes kopiert werden, und zwar an vierter Stelle:

        <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/java"/>
        <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/resources"/>

Die Logik dahinter ist mir schleierhaft, da ja davon eigentlich auszugehen ist, dass das JPA-Plugin die persistence.xml aus dem Classpath anzieht.

Vor ein paar Tagen wurde ich bei Twitter von dem stopmakesense-Bot retweetet und dachte mir da nichts bei. Ich hatte geschrieben: “Das macht keinen Sinn.” Während einer Besprechung am Montag, wurde ich auf meinen Fehler noch einmal dezent hingewiesen – ignorierte es aber.

Heute Morgen beim Schwimmen fiel mir der sprachliche Unfall wieder ein und ich dachte darüber nach, was denn daran falsch sei. Ich behaupte einfach mal, dass jeder, der “das macht keinen Sinn” als falsch ansieht und jünger als 35 ist, den Artikel bei Zwiebelfisch gelesen hat, nachdem entweder vor sieben Jahren darüber in seinem RSS-Reader gestolpert ist (bin ich nicht) oder aber von dem oben genannten Twitter-Bot in den letzten Monaten/Wochen retweetet wurde.

Wie dem auch sei. Im Duden steht bereits seit 2002, dass “das macht keinen Sinn” als umgangssprachlich anerkannt ist - was mir auf den Keks geht, ist die Begründung, die Bastian Sick als Autor von “Der Dativ ist dem Genitiv sein Tod” und anderen Büchern über die deutsche Sprache verfasst hat und was sich damit anstellen lässt:

‘”Sinn” und “machen” passen einfach nicht zusammen. Das Verb “machen” hat die Bedeutung von fertigen, herstellen, tun, bewirken; es geht zurück auf die indogermanische Wurzel mag-, die für “kneten” steht. Das erste, was “gemacht” wurde, war demnach Teig. Etwas Abstraktes wie Sinn lässt sich jedoch nicht kneten oder formen. Er ist entweder da oder nicht. Man kann den Sinn suchen, finden, erkennen, verstehen, aber er lässt sich nicht im Hauruck-Verfahren erschaffen’

Ich akzeptiere die Begründung so wie sie ist. Ich muss sogar zugeben, dass ich bis dahin dachte: “It doesn’t make sense” falsches Englisch sei – ich bin damit sicherlich nicht alleine. Hiermit mal alle an die eigene Nase fassen.

Soweit, so gut. Jetzt mal an alle, die sich für “das macht keinen Sinn” einsetzen und den zitierten Satz von Bastian Sick gelesen haben: Haltet ihr die Aussage “Das macht Laune” oder noch besser “Das macht doch keinen Spaß!” jetzt noch für richtig?

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.

Damit bei einem Segmentation Fault eine Core-Dump erzeugt wird, muss

ulimit -c unlimited

aufgerufen. Damit wird festgelegt, dass der Core-Dump beliebig groß sein darf.

Mit

gdb a.out core
backtrace

lassen sich die letzten Ausführungsschritte der Applikation anzeigen.

Mit

apt-get install valgrind
valgrind --tool=memcheck --leak-check=yes ./a.out

lässt sich überprüfen, welche Funktionen potenzielle Memory Leaks erzeugen, die wiederum zu einem Segmentation Fault führen können.

<opml version="1.0">
  <head>
    <title>Feeds</title>
  </head>
  <body>
    <outline text="Feeds">
    {
	let $d := fn:doc("/home/ckl/Desktop/feeds.xml")/feeds
        for $x in $d/feed
            return
		<outline title="{$x/Title}" xmlUrl="{$x/Link}" />
    }
</outline>
</body>
</opml>

// _xmlFiles = new String[] { "config.xml" }
// false = Context noch nicht initalisieren
ClassPathXmlApplicationContext ac = new ClassPathXmlApplicationContext(
_xmlFiles, false);
// PropertyPlacer aufsetzen, so dass die Konfiguration geladen werden kann
PropertyPlaceholderConfigurer cfg = new PropertyPlaceholderConfigurer();
Resource resource  = ac.getResource("my.properties");

if (resource == null)
{
throw new InvalidParameterException(
"Could not load configuration");
}

// Location setzen
cfg.setLocation(resource);
// Dem ApplicationContext den PostProcessor anfügen
ac.getBeanFactoryPostProcessors().add(cfg);

// ApplicationContext (neu) laden
ac.refresh();

Warum ich das poste? Die Spring-Dokumentation schlägt vor, dass anstatt ac.getBeanFactoryPostProcessors() cfg.setBeanFactory(ac.getBeanFactory()) benutzt werden soll. Das funktioniert aber nicht, weil in dem Moment der ApplicationContext noch gar nicht geladen wurde und es dann zu Exceptions kommt.