Spring 2.5
Das ist neu
Kaum ein Java Entwickler, der heute noch am Spring Framework vorbeikommt. Wie aus einem Guß lassen sich mit Spring einzelne Bausteine, die sogenannten Spring Beans, zusammensetzen. Wir selbst haben schon einige Projekte mit Hilfe des Spring Frameworks realisiert. Mit der vor kurzem veröffentlichten finalen Version 2.5, kommen wieder ein paar neue Features dazu. So richtig viele gute Tutorials zu Spring 2.5 gibt es heute, rund drei Wochen nach dem Release noch nicht. Ich habe heute mal ein paar neue Features rausgegriffen, die ich als Java Entwickler sehr spannend finde.
Im Bereich Autowiring hat sich in Spring 2.5 einiges getan. Offensichtlich hat man hinterfragt, warum zwar viele Entwickler in Unit Tests auf Autowiring setzen, sich in der produktiven Applikation aber lieber auf die manuelle Konfiguration verlassen. Spring 2.5 bietet bessere Möglichkeiten das Autowiring granular einzustellen. Bisher konnten Beans nur über Type, Name, Constructor oder automatisch autowired werden. Neu ist nun die Klasse AutowiredAnnotationBeanPostProcessor, die man als Bean in seiner XML Konfiguration hinzufügen muss, um von den verbesserten Konfigurationsmöglichkeiten Gebrauch zu machen. Entweder so:
oder kürzer mit Hilfe des "Context" Namespaces:
Dafür gibt es dann ein paar nette neue Annotationen. Beispielsweise @Autowired, mit der man private Membervariablen, Methoden oder Konstruktoren annotieren kann. Werden Methoden mit @Autowired annotiert, übernehmen die quasi das Verhalten der ehemaligen Setter-Injection, können allerdings beliebig heißen und sogar Parameter haben. Jede mit @Autowired markierte private Membervariable muss zu einem Pendant in der Spring Konfiguration aufgelöst werden können - gilt also als required. Kann die Abhängigkeit nicht aufgelöst werden (in diesem Fall über den Type) kommt es zu einer Exception. Wer das vermeiden will, kann das Attribute required der Annotation auf false setzen.
Dadurch kann man für ein default-Verhalten sorgen. Soll nicht über den Type sondern den Namen aufgelöst werden, nimmt man die neue @Qualifier Annotation:
Die @Qualifier Annotation kann man sogar einem Parameter einer Methode voranstellen, wenn diese mit @Autowired ausgezeichnet wurde. Das ganze sieht dann etwas ungewöhnlich aus:
Ein Paradigma von Spring ist es, Code und Framework so stark wie möglich voneinander zu trennen. Mit der @Autowired Annotation ist es jetzt möglich, dass Objekte Zugriff auf Instanzen vom ApplicationContext, der MessageSource oder ganz abstrakt den ResourceLoader erhalten, ohne das diese wie bisher von ResourceLoaderAware oder ApplicationContextAware ableiten müssen. Die entsprechenden Interfaces müssen nicht mehr implementiert werden. Die Kopplung wird geschwächt.
Kommen wir zu einer Verbesserung, die für mich den größten Fortschritt darstellt. In Spring 2.0 wurde bereits die Annotation @Resource eingeführt. Mit Spring 2.5 kommen drei weitere Annotationen dazu - @Component, @Service und @Controller. Die beiden letzten dienen nur der Semantik während @Component rein generisch sein soll. Alle mit @Component, @Service oder @Controller annotierten Bean Klassen, können sich selbst konfigurieren und kommen im Endeffekt, dank @Autowired, völlig ohne XML Konfiguration aus. Mit nur einer Zeile in der applicationContext.xml Datei, lässt sich die Autokonfiguration anschalten:
Die Angabe eines base-packages ist dabei erforderlich. Die Angabe mehrerer Packages, ist als komma-separierte Liste möglich. Alle Beans innerhalb der base-packages, die mit @Component oder deren Derivaten annotiert sind, werden automatisch konfiguriert. Besonders mächtig wird das im Zusammenhang mit Spring MVC und den dort vorhandenen Controller Klassen. Ab Spring 2.5 kann jede beliebige Klasse als Controller annotiert werden, ohne das von einer vorgegebenen Controller-Klasse (z.B. SimpleFormController) abgeleitet werden muss. Auch hier spürt man deutlich, wie die Macher von Spring versuchen, so wenig wie möglich Vorgaben zu machen.
Und so funktionieren die konfigurationslosen Controller. Die Klasse wird mit @Controller annotiert und dadurch über context:component-scan automatisch konfiguriert. Das Mapping des Controllers auf eine URI, erfolgt über die neue @RequestMapping Annotation, z.b. @RequestMapping("/reply.do"). Mit @RequestMapping lassen sich Methoden annotieren. Solch eine Methode kann über beliebig viele Parameter in der Signatur verfügen. Werden diese Parameter mit der, ebenfalls neuen, Annotation @RequestParam("paramName") ausgezeichnet, erfolgt ein automatisches Mapping auf den entsprechend benannten Request Parameter. Oha - autokonfigurierte Controller ohne Abhängigkeit zur Servlet API. Klingt ein wenig wie JBoss Seam, auch wenn die gar keine Controller haben und direkt auf den Entity Beans annotieren.
Auch für die Liebhaber der aspektorientierten Programmierung bietet die neue Spring Version eine kleine Erweiterung. Version 2.5 führt mit "bean(..)" einen neuen Pointcut in die Spring-AspectJ Syntax ein. Damit lassen sich ein oder mehrere Spring Beans über den Klassennamen selektieren. Eine schöne grafische Darstellung auf dem Interface21 Blog verdeutlicht das besser als Tausend Worte.
Die letzte Verbesserung die nicht unerwähnt bleiben soll, betrifft das Unit Testen mit JUnit. Bisher unterstützte Spring lediglich JUnit 3.8. Grund dafür war die Notwendigkeit, für Spring Unit Tests von verschiedenen Basis Testklassen aus dem Test Package (z.B. AbstractDependencyInjectionSpringContextTests) ableiten zu müssen. Das ist zwar weiterhin möglich, trotzdem geht Spring 2.5 einen anderen Weg. In Zukunft erledigen Annotationen die Funktionalität, die sonst durch die Superklassen bereitgestellt wird. Statt wie bisher die Methode getConfigLocations() zu überschreiben, verwendet man zukünftig die @ContextConfiguration Annotation und gibt dort alle XML-Konfigurationsdateien an. Wie bisher werden Testklasse autowired. Das funktioniert nun über die beschriebene @Autowired Annotation. Die bisheren Methoden onSetUpInTransaction(..) und onTearDownInTransaction(..) werden durch die JUnit4 Annotationen @Before und @After ersetzt. Für die transaktionen Setup und Teardown Methoden onSetUpBeforeTransaction(..) bzw. onTearDownAfterTransaction(..) bringt Spring 2.5 zwei neue, eigene Annotationen mit. Sie heißen @BeforeTransaction und @AfterTransaction.
Wie geht Spring 2.5 mit transaktionalen Testklassen, die bisher durch Basisklassen wie AbstractTransactionalSpringContextTests realisiert wurden, um. Hier wird dem Anwender etwas mehr Arbeit abverlangt. Test-Methoden, die nach der Ausführung in der Datenbank zurück gerollt werden sollen, sind nun mit @Transactional zu annotieren. Der Mehraufwand ermöglicht aber auch eine größere Flexibilität. Das Verhalten einzelner Testmethoden lässt sich nur granular neben @Transactional mit weiteren Annotationen wie @NotTransactional oder @Rollback steuern. Wer noch mehr über Junit 4 und Spring 2.5 erfahren will, dieser Blogeintrag geht noch mehr ins Detail.
Über weitere Verbesserungen wird man in Zukunft mehr lesen. Jetzt gilt es zunächst selbst neue Projekte mit dem neuen Spring umzusetzen.
Im Bereich Autowiring hat sich in Spring 2.5 einiges getan. Offensichtlich hat man hinterfragt, warum zwar viele Entwickler in Unit Tests auf Autowiring setzen, sich in der produktiven Applikation aber lieber auf die manuelle Konfiguration verlassen. Spring 2.5 bietet bessere Möglichkeiten das Autowiring granular einzustellen. Bisher konnten Beans nur über Type, Name, Constructor oder automatisch autowired werden. Neu ist nun die Klasse AutowiredAnnotationBeanPostProcessor, die man als Bean in seiner XML Konfiguration hinzufügen muss, um von den verbesserten Konfigurationsmöglichkeiten Gebrauch zu machen. Entweder so:
<bean class="org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor"/>
oder kürzer mit Hilfe des "Context" Namespaces:
<context:annotation-config/>
Dafür gibt es dann ein paar nette neue Annotationen. Beispielsweise @Autowired, mit der man private Membervariablen, Methoden oder Konstruktoren annotieren kann. Werden Methoden mit @Autowired annotiert, übernehmen die quasi das Verhalten der ehemaligen Setter-Injection, können allerdings beliebig heißen und sogar Parameter haben. Jede mit @Autowired markierte private Membervariable muss zu einem Pendant in der Spring Konfiguration aufgelöst werden können - gilt also als required. Kann die Abhängigkeit nicht aufgelöst werden (in diesem Fall über den Type) kommt es zu einer Exception. Wer das vermeiden will, kann das Attribute required der Annotation auf false setzen.
@Autowired(required=false)
private Town _town = new GermanTown();
private Town _town = new GermanTown();
Dadurch kann man für ein default-Verhalten sorgen. Soll nicht über den Type sondern den Namen aufgelöst werden, nimmt man die neue @Qualifier Annotation:
@Autowired
@Qualifier("germanTown")
private Town _town;
@Qualifier("germanTown")
private Town _town;
Die @Qualifier Annotation kann man sogar einem Parameter einer Methode voranstellen, wenn diese mit @Autowired ausgezeichnet wurde. Das ganze sieht dann etwas ungewöhnlich aus:
@Autowired
public void initTown(@Qualifier("germanTown") Town town) { ..
public void initTown(@Qualifier("germanTown") Town town) { ..
Ein Paradigma von Spring ist es, Code und Framework so stark wie möglich voneinander zu trennen. Mit der @Autowired Annotation ist es jetzt möglich, dass Objekte Zugriff auf Instanzen vom ApplicationContext, der MessageSource oder ganz abstrakt den ResourceLoader erhalten, ohne das diese wie bisher von ResourceLoaderAware oder ApplicationContextAware ableiten müssen. Die entsprechenden Interfaces müssen nicht mehr implementiert werden. Die Kopplung wird geschwächt.
Kommen wir zu einer Verbesserung, die für mich den größten Fortschritt darstellt. In Spring 2.0 wurde bereits die Annotation @Resource eingeführt. Mit Spring 2.5 kommen drei weitere Annotationen dazu - @Component, @Service und @Controller. Die beiden letzten dienen nur der Semantik während @Component rein generisch sein soll. Alle mit @Component, @Service oder @Controller annotierten Bean Klassen, können sich selbst konfigurieren und kommen im Endeffekt, dank @Autowired, völlig ohne XML Konfiguration aus. Mit nur einer Zeile in der applicationContext.xml Datei, lässt sich die Autokonfiguration anschalten:
<context:component-scan base-package="de.kanzelbahn.spring"/>
Die Angabe eines base-packages ist dabei erforderlich. Die Angabe mehrerer Packages, ist als komma-separierte Liste möglich. Alle Beans innerhalb der base-packages, die mit @Component oder deren Derivaten annotiert sind, werden automatisch konfiguriert. Besonders mächtig wird das im Zusammenhang mit Spring MVC und den dort vorhandenen Controller Klassen. Ab Spring 2.5 kann jede beliebige Klasse als Controller annotiert werden, ohne das von einer vorgegebenen Controller-Klasse (z.B. SimpleFormController) abgeleitet werden muss. Auch hier spürt man deutlich, wie die Macher von Spring versuchen, so wenig wie möglich Vorgaben zu machen.
Und so funktionieren die konfigurationslosen Controller. Die Klasse wird mit @Controller annotiert und dadurch über context:component-scan automatisch konfiguriert. Das Mapping des Controllers auf eine URI, erfolgt über die neue @RequestMapping Annotation, z.b. @RequestMapping("/reply.do"). Mit @RequestMapping lassen sich Methoden annotieren. Solch eine Methode kann über beliebig viele Parameter in der Signatur verfügen. Werden diese Parameter mit der, ebenfalls neuen, Annotation @RequestParam("paramName") ausgezeichnet, erfolgt ein automatisches Mapping auf den entsprechend benannten Request Parameter. Oha - autokonfigurierte Controller ohne Abhängigkeit zur Servlet API. Klingt ein wenig wie JBoss Seam, auch wenn die gar keine Controller haben und direkt auf den Entity Beans annotieren.
Auch für die Liebhaber der aspektorientierten Programmierung bietet die neue Spring Version eine kleine Erweiterung. Version 2.5 führt mit "bean(..)" einen neuen Pointcut in die Spring-AspectJ Syntax ein. Damit lassen sich ein oder mehrere Spring Beans über den Klassennamen selektieren. Eine schöne grafische Darstellung auf dem Interface21 Blog verdeutlicht das besser als Tausend Worte.
Die letzte Verbesserung die nicht unerwähnt bleiben soll, betrifft das Unit Testen mit JUnit. Bisher unterstützte Spring lediglich JUnit 3.8. Grund dafür war die Notwendigkeit, für Spring Unit Tests von verschiedenen Basis Testklassen aus dem Test Package (z.B. AbstractDependencyInjectionSpringContextTests) ableiten zu müssen. Das ist zwar weiterhin möglich, trotzdem geht Spring 2.5 einen anderen Weg. In Zukunft erledigen Annotationen die Funktionalität, die sonst durch die Superklassen bereitgestellt wird. Statt wie bisher die Methode getConfigLocations() zu überschreiben, verwendet man zukünftig die @ContextConfiguration Annotation und gibt dort alle XML-Konfigurationsdateien an. Wie bisher werden Testklasse autowired. Das funktioniert nun über die beschriebene @Autowired Annotation. Die bisheren Methoden onSetUpInTransaction(..) und onTearDownInTransaction(..) werden durch die JUnit4 Annotationen @Before und @After ersetzt. Für die transaktionen Setup und Teardown Methoden onSetUpBeforeTransaction(..) bzw. onTearDownAfterTransaction(..) bringt Spring 2.5 zwei neue, eigene Annotationen mit. Sie heißen @BeforeTransaction und @AfterTransaction.
Wie geht Spring 2.5 mit transaktionalen Testklassen, die bisher durch Basisklassen wie AbstractTransactionalSpringContextTests realisiert wurden, um. Hier wird dem Anwender etwas mehr Arbeit abverlangt. Test-Methoden, die nach der Ausführung in der Datenbank zurück gerollt werden sollen, sind nun mit @Transactional zu annotieren. Der Mehraufwand ermöglicht aber auch eine größere Flexibilität. Das Verhalten einzelner Testmethoden lässt sich nur granular neben @Transactional mit weiteren Annotationen wie @NotTransactional oder @Rollback steuern. Wer noch mehr über Junit 4 und Spring 2.5 erfahren will, dieser Blogeintrag geht noch mehr ins Detail.
Über weitere Verbesserungen wird man in Zukunft mehr lesen. Jetzt gilt es zunächst selbst neue Projekte mit dem neuen Spring umzusetzen.
