Spring Konfiguration mit Annotations
Mike Wiesner
mit Spring 2.1 wird die Unterstützung von Annotations nochmals erweitert
werden. Bei Spring 2.0 wurde ja schon @Repository, @Required,
@Transactional und die AspectJ-Annotation-Syntax eingeführt.
Bei Spring 2.1 geht es jetzt soweit, das die komplette Spring
Konfiguration über Annotations gemacht werden kann. Die bisherige
Konfiguration mit XML bleibt natürlich trotzdem vorhanden und wird auch
nicht deprecated, vielmehr wird dadurch eine Alternative angeboten die
in einigen Bereichen vielleicht ganz interessant sein dürfte.
Wenn bei Spring 2.1 ein Service z.B. einen DAO benötigt kann dies dann
durch folgenden Code geschehen:
@Autowired
private void setMeinTollerDao(MeinTollerDao dao)
Der Service kann dann entweder mit folgender Konfiguration angelegt werden:
<bean class="service.MeinTollerService"/>
..oder aber von Spring "gesucht" werden:
<context:component-scan base-package="service"/>
Dazu muss dann bei der Klasse noch die Annotation @Component hinzugefügt
werden.
Der DAO kann dann z.B. wiederum in einer Spring-XML-Datei konfiguriert
sein oder ebenfalls über @Component erstellt werden. Es ist also auch
beliebiges mischen möglich, und mit @Resource kann auch ein explizites
Mapping auf eine Spring Bean anstatt autowire gemacht werden.
Weiterhin werden auch die JSR-250 Annotations @PostConstruct und
@PreDestroy unterstützt.
Eine Step-by-Step Anleitung dazu gibt es hier:
http://blog.interface21.com/main/2007/05/14/annotation-driven-dependency-injection-in-spring-21/
Was ist eure Meinung dazu, und habt ihr vielleicht sogar konkrete
Anwendungsfälle für diese Art der Konfiguration?
Grüße,
Mike
--
Mike Wiesner
Senior Consultant
Interface21 GmbH - Spring Services from the Source
Sitz der Gesellschaft: Brentanostr. 52a - D-12163 Berlin
Geschäftsführer: Steven Schuurman, Rod Johnson
Amtsgericht Charlottenburg - HRB 103773 B
Phone: +49 157 721 786 37
Mail: mwie...@interface21.com
Skype: mike.wiesner
Blog: http://www.mwiesner.com
Mailing List: http://lists.interface21.com/listmanager/listinfo/news-de
ThorQue
On 16 Mai, 15:07, Mike Wiesner <mwies...@interface21.com> wrote:
> Wenn bei Spring 2.1 ein Service z.B. einen DAO benötigt kann dies dann
> durch folgenden Code geschehen:
>
> @Autowired
> private void setMeinTollerDao(MeinTollerDao dao)
Und das bedeutet jetzt, dass ich den Service von Spring abhängig
gemacht habe, da die Annotation ja aus einem Spring-Package stammt.
Wie passt das zur Aussage das Spring minimal invasiv ist?
Geht man nicht einen Schritt zurück, nachdem man mühsam den
Entwicklern erklärt hat, wie man seine Services technologieneutral
gestalten sollte?
Viele Grüsse
Thorsten
Oliver Schlicht
nunja, es heißt du KANNST mit Spring minimalinvasiv arbeiten, du MUSST
aber nicht. Argumtent für SpringMVC gegenüber Struts ist ja auhc
gewesen, dass es reicht, ein Interface zu implementieren und man nicht
ZWINGEND von einer Klasse erben muss. Jedoch macht man das im Großteil
der Fälle dann ja doch (SimpleFormController).
Spring lässt dir die Wahl, daher ist die Aussage auch bei der
aktuellen Entwicklung meiner Meinung nach nicht falsch. Ich steh dem
Thema Annotations und Autowiring auch skeptisch gegenüber. Zum einen
bindet es dann tatsächlich die Implementierung an die Technologie zum
anderen macht Autowiring das System meiner Meinung nach dahingehen
instabil, als das ich oder ein anderer Entwickler nicht einfach eine
Klasse hinzufügen kann ohne die Möglichkeit, das die das Autowiring
evtl. durcheinander bringt (falls sie auch das per autowiring
annotierte Interface implementiert).
Ich find, dass momentan viele Sachen hinzukommen, die relativ exotisch
sind bzw. zwar eine interessante, aber keine wirklich produktiv
gewinnbringende Alternative zu bereits bestehenden
Konfigurationsmitteln darstellen. Zumal es dadurch nicht einfacher
wird, den Überblick zu behalten. Ich kann mich erinnern, dass bei EJB3
auch viele geschimpft haben, dass es durch das Hinzufügen der
Annotations auch KOMPLIZIERTER wurde - durch die Möglichkeit
Konfigurationstypen zu mischen. Was ich meine ist, dass es einen
gewissen Mehraufwand benötigt, die verschiedenen Konfigurationstypen
sinnvoll zu überblicken und in Projekten zu verwalten (was macht man
mit was?). Dieser Mehraufwand frisst meiner Meinung nach den Vorteil,
den eine Annotation evtl. bringt wieder auf. Zumal dieses Vorgehen
auch den Grundsatz der zentralen Konfiguration wieder ad absurdum
führt (gern gebrachte Kritik an "AOP" bei EJB3).
Interessant finde ich hingegen die Entwicklung der JavaConfig (http://
blog.interface21.com/main/2006/11/28/a-java-configuration-option-for-
spring/) für Spring. Dann allerdings als kompletten Ersatz für die XML
Konfiguration. So könnte man während der Entwicklung mit XML arbeiten,
die Flexibiltät beim Umbau nutzen und im Produktivbetrieb dann auf die
kompilierbare Klasse wechseln, die damit weniger typofehleranfällig
ist als das XML. Hier stören dann auch Annotations nicht, da die
Konfiguration ja so oder Spring spezifisch ist.
Meine 0.02€
Ollie
Mike Wiesner
Nun, zurück sowieso nicht, weil es ja eine alternative ist bei der jeder
selbst entscheiden kann ob er diese nutzen will (daher auch der Anstoss
dieser Diskussion). Viele der Annotations können auch durch eigene
ersetzt werden und Spring wird dann mitgeteilt nach welchen es suchen
soll. Das geht mit Spring 2.0 z.B. schon mit @Required, dort kann man
seine eigene @MyRequired Annotation erzeugen und teilt Spring einfach
mit das er diese verwenden soll. Somit hat man auch hier keine
Abhängigkeit zu Spring und kann aber trotzdem die Vorteile nutzen.
Die Abhängigkeit sollte also das geringste Problem sein (weil eben
abstellbar), viel entscheidender ist ja ob ihr für diese Art der
Konfiguration momentan einen Einsatzzweck seht?
Grüße,
Mike
--
Mike Wiesner
Senior Consultant
Interface21 GmbH - Spring Services from the Source
Sitz der Gesellschaft: Brentanostr. 52a - D-12163 Berlin
Geschäftsführer: Steven Schuurman, Rod Johnson
Amtsgericht Charlottenburg - HRB 103773 B
Phone: +49 157 721 786 37
Mail: mwie...@interface21.com
Skype: mike.wiesner
Blog: http://www.mwiesner.com
Mailing List: http://lists.interface21.com/listmanager/listinfo/news-de
Attend SpringOne 2007, Interface21's developer conference covering the
Spring Portfolio products.
42 Sessions in 3 Parallel Tracks
June 20 - 22, 2007 - Antwerp, Belgium
www.springone.com
Eberhard Wolff
Es ist - wie so oft - ein Trade-Off. Ein wichtiger Punkt bei Spring ist
die Freiheit, sich eine Lösung herauszusuchen. Deswegen zwingt Spring
beispielsweise auch nicht das eigene Web-Framework auf, sondern bietet
auch die Möglichkeit, andere Web-Frameworks zu integrieren.
Spannend ist der Poll auf den Spring Foren:
http://forum.springframework.org/showthread.php?t=35947 . Hier zeigt
sich, dass recht viele Leute @Required für Dependency Checks nutzen. Bei
Transaktionen ist @Transaction sogar am beliebtesten (
http://forum.springframework.org/showthread.php?t=37178 ). Die Nutzer
finden solche Möglichkeiten also gut und verwenden sie. Unser Bestreben
ist natürlich, die Spring-User möglichst zufrieden zu stellen. Und bei
einer Einführung in Spring kommt auch typischerweise sehr schnell
kritische Fragen zu der XML-Konfiguration. Durch Guice hat sich
ebenfalls gezeigt, dass solche DI-Möglichkeiten beliebt sind.
Interessanterweise sind diese Annotationen zum Teil durch JSR 250
standardisiert.
Der Nutzer hat also die Wahl: Annotationen für DI mit recht guter
Benutzbarkeit, aber den zitierten Abhängigkeiten. Oder XML mit den
eigenen XML-Namespaces oder eben das auch schon erwähnte Spring
JavaConfig, mit man die Konfiguration mit Annotationen und Java
festlegt, ohne aber Abhängigkeiten im eigentlichen Code zu haben. Und da
wird man sich entscheiden müssen. Die neuen Annotationen empfinde ich
jedenfalls als sinnvolle Ergänzung.
Gruß,
Eberhard
--
Eberhard Wolff
Managing Consultant
Interface21 GmbH - Spring Services from the Source
Sitz der Gesellschaft: Brentanostr. 52a - D-12163 Berlin
Geschäftsführer: Steven Schuurman, Rod Johnson
Amtsgericht Charlottenburg - HRB 103773 B
Author, "Spring - Framework für die Java Entwicklung"
http://www.spring-buch.de/
Founding Member Java Champions
https://java-champions.dev.java.net/
Phone: +49 177 880 96 18
Mail: eberhar...@interface21.com
Skype: ebr.wolff
Blog: http://JandIandMe.blogspot.com/
Audiocast: http://se-radio.net/
Mailing List: http://lists.interface21.com/listmanager/listinfo/news-de
ThorQue
ich wollte nicht den Miesepeter spielen und es alles schlechtreden :)
Worum es mir eigentlich ging ist das Problem der Spring-Abhängigkeit.
Wenn ich die XML-Konfiguration mit JPA und den Annotations verwende,
bekomme ich ein System hin (fast) ohne konkrete Abhängigkeiten zu
einer Technologie. D.h. der Code ist erst mal unabhängig davon, ob ich
Hibernate, TopLink oder Spring verwende.
So weit so gut...
Annotations für die Konfiguration zu verwenden finde ich persönlich
auch sehr chic. Man hat Code und Konfiguration beisammen und die doch
länglichen XML-Konfigurationen sind deutlich handlicher. Aber wie
sieht das mit dem Toolsupport aus? Kann das die SpringIDE? Sehe ich
dort sämtliche Komponenten meiner Anwendung (das habe ich bisher noch
nicht ausprobiert)? Hat da jemand bereits Erfahrungen mit gesammelt?
Gibt es eigentlich Pläne, um die Spring Annotations zu
standardisieren? Bzw. Spring selbst zum (JSR-)Standard zu machen.
Somit wären diese leidige Diskussionen (aber EJB ist Standard und
Spring nicht!) auch vorbei.
@Mike: Du schriebst, dass man auch eigene Annotations definieren kann
und Spring mitteilen. Gibt es da etwas Doku zu?
Thorsten
Mike Wiesner
ThorQue schrieb:
>
> @Mike: Du schriebst, dass man auch eigene Annotations definieren kann
> und Spring mitteilen. Gibt es da etwas Doku zu?
>
Du baust einfach deine eigene Annotation und übergibst diese dem
RequiredAnnotationBeanPostProcessor:
<bean
class="org.springframework.beans.factory.annotation.RequiredAnnotationBeanPostProcessor">
<property name="requiredAnnotationType"
value="your.company.package.Mandatory"/>
</bean>
Grüße,
Mike
Juergen Hoeller
Tool-Support ist natürlich wichtig: SpringIDE wird dort entsprechend
nachziehen. Wie schon bei den XML-Namespaces wird dies aber erst eine Weile
nach dem 2.1-Framework-Release verfügbar sein... das ist leider
unvermeidlich.
Bezüglich Standardisierung: @PostConstruct, @PreDestroy und @Resource - so
wie in Spring 2.1 M1 unterstützt - SIND bereits standardisiert, im Rahmen
des JSR-250 ("Common Annotations for the Java Platform"). Diese Annotations
werden sogar im JDK 1.6 out of the box mitgeliefert! Dies ist auch ein
Hauptgrund, warum Spring 2.1 - im Rahmen seines generellen Java 6 Support -
diese Annotations unterstützt.
Die JSR-250 Annotations sind auch Teil der Java EE 5, insbesondere für JSF
1.2 Managed Beans und EJB 3.0 Session/Message-Driven Beans. Spring
unterstützt hiermit ein standardisiertes Konfigurationsmuster und sorgt für
Konsistenz bei Anwendungen, in denen Spring und JSF 1.2 (oder auch EJB 3.0)
gemeinsam zum Einsatz kommen - also insbesondere bei Spring-Anwendungen, die
auf Java EE 5 aufbauen.
Die nicht-standardisierten Annotations in Spring sind derzeit
@Transactional, @Required und @Autowired, sowie @Repository und @Component.
Für all diese außer @Transactional erlaubt Spring, einfach eigene
Annotations (mit äquivalenter Semantik) zu spezifizieren; als
@Transactional-Alternative kann man z.B. maßgeschneiderte Pointcuts
verwenden. Natürlich kann man auch einfach auf Annotations verzichten...
Dabei gibt es @Transactional schon seit Spring 1.2, sowie @Required /
@Repository seit Spring 2.0. Annotation-Support in Spring ist also
keineswegs neu; Spring 2.1 geht hier einfach den nächsten Schritt - unter
besonderer Berücksichtigung von Java 6 un Java EE 5. Und gleichzeitig unter
Beibehaltung von JDK-1.4-Kompatibilität, womit automatisch garantiert ist,
dass es immer Varianten ohne Annotations gibt!
Jürgen
Christian Dupuis
> nachziehen. Wie schon bei den XML-Namespaces wird dies aber erst eine Weile
> nach dem 2.1-Framework-Release verfügbar sein... das ist leider
> unvermeidlich.
Um die Frage nach Tool-Support mal ein bißchen genauer zu beantworten:
Spring IDE wird sehr schnell (wahrscheinlich noch mit 2.0 final bzw.
kurz danach) die @Component und @Repository Annotation unterstützen.
Auch werden wir bestehende Beans oder @Component bzw. @Repository
annotierte Klassen nach @Resource annotations untersuchen und
entsprechende Bean-dependencies generieren.
Wir werden dies relativ schnell unterstützen können, da mit dem
letzten post-M4 builds bereits Support für Spring JavaConfig umgesetzt
worden ist und wir hier die selbe Infrastruktur nutzen können.
Bisher nicht geplant ist Unterstützung für Autowiring entweder per XML
Konfiguration oder per @Autowired. Dies ist ein bißchen zu "magisch"
für unsere eingeschränkte Laufzeitumgebung.
Gruß
Christian
--
Spring IDE
Tool support for Spring development
http://springide.org
Juergen Hoeller
Um mich etwas klarer auszudrücken: Natürlich ist das Ziel, Tool-Support so
schnell wie möglich anzubieten. Allerdings wird es immer Framework-Releases
(insbesondere Milestones und Release Candidates) bereits vor den zugehörigen
Tool-Releases geben. Dies liegt in der Natur der Sache, insbesondere bei
agiler Framework-Entwicklung...
Ein Nachtrag auch noch zum Thema Standardisierung:
Spring wird auch weiterhin aufkommende Standard-Annotationen unterstützen,
soweit möglich und sinnvoll. Z.B. könnte die JavaBeans-Spec ein
Standard-@Required für Bean-Property-Setter einführen... oder ein JSR für
Common Annotations 1.1/2.0 entstehen, der auch Dinge wie Constructor
Autowiring durch eine Annotation unterstützt.
Bei @Transactional, einem weiteren wichtigen Punkt in dieser Hinsicht, gibt
Spring einiges an spezifischen Optionen vor: z.B. das für O/R-Mapper
wichtige "readOnly"-Flag oder auch einen Isolation-Level. Eine
Standard-Transaktions-Annotation sollte auch diese Optionen unterstützen
(was z.B. das EJB3 TransactionAttribute nicht tut), ansonsten wird sie in
einer Spring-Umgebung kaum jemand freiwillig einsetzen.
In all diesen Fällen sollten wir allerdings nicht von einer
"Standardisierung von Spring" sprechen. Hier geht es um spezifische
Annotationen im Rahmen eines allgemeinen Komponentenmodells für
Java/Java-EE, die z.B. auch von JSF und/oder EJB unterstützt werden können.
Die Spring-spezifischen Annotations würden hier in verschiedene bestehende
Specs einfließen, nicht unbedingt eine eigene Spec werden.
ThorQue
gilt das nur für die Required Annotation oder können auch andere
Annotations so selbst definiert werden?
Und gibts das auch für 2.0?
Viele Grüsse
Thorsten
On 21 Mai, 09:15, Mike Wiesner <mwies...@interface21.com> wrote:
> Hi,
>
> ThorQue schrieb:
>
> > @Mike: Du schriebst, dass man auch eigene Annotations definieren kann
> > und Spring mitteilen. Gibt es da etwas Doku zu?
>
> Gibt es:http://static.springframework.org/spring/docs/2.1.x/reference/metadat...
ThorQue
On 21 Mai, 12:49, "Juergen Hoeller" <juer...@interface21.com> wrote:
> Tool-Support ist natürlich wichtig: SpringIDE wird dort entsprechend
> nachziehen. Wie schon bei den XML-Namespaces wird dies aber erst eine Weile
> nach dem 2.1-Framework-Release verfügbar sein... das ist leider
> unvermeidlich.
Mit etwas Zeitverzögerung ist ja immer zu rechnen...aber es scheint
diesmal ja alles recht zeitnah zu passieren...
>
> Bezüglich Standardisierung: @PostConstruct, @PreDestroy und @Resource - so
> wie in Spring 2.1 M1 unterstützt - SIND bereits standardisiert, im Rahmen
> des JSR-250 ("Common Annotations for the Java Platform"). Diese Annotations
> werden sogar im JDK 1.6 out of the box mitgeliefert! Dies ist auch ein
> Hauptgrund, warum Spring 2.1 - im Rahmen seines generellen Java 6 Support -
> diese Annotations unterstützt.
Ja, das habe ich mir heute morgen auch direkt angesehen, da Eberhard
das in seinem Posting erwähnte.
>
> Die nicht-standardisierten Annotations in Spring sind derzeit
> @Transactional, @Required und @Autowired, sowie @Repository und @Component.
> Für all diese außer @Transactional erlaubt Spring, einfach eigene
> Annotations (mit äquivalenter Semantik) zu spezifizieren; als
> @Transactional-Alternative kann man z.B. maßgeschneiderte Pointcuts
> verwenden. Natürlich kann man auch einfach auf Annotations verzichten...
Genau darum ging es mir. Ich denke, dass es problematisch wird, wenn
man die Konfigurationstypen mischt. Ab einem gewissen Punkt weiss man
nicht mehr genau wo etwas konfiguriert ist. Da wäre ein einheitliches
Vorgehen innerhalb eines Projekts sinnvoll.
Was ich bei meinem ersten Posting nicht wusste ist, dass man die
Annotations quasi überschreiben und somit kapseln kann. Somit ist der
Code ja grundsätzlich wieder frei von direkten Abhängigkeiten. Nur die
eigen spezifizierten Annotations haben diese Abhängigkeit. Was aber
kein grosses Problem sein sollte.
Wahrscheinlich ist für diese Diskussion eher theoretischer Natur, da
man wahrscheinlich nicht von Spring auf etwas anderes wechseln möchte
(wird).
Viele Grüsse
Thorsten
Gidion
ich persönlich sehe zur Zeit in Annotations eher Nachteile.
Zum einen wegen der bereits angesprochenen Unübersichtlichtkeit, wenn
ich mir meinen Code in Eclipse ansehe, kann ich bei verwendung der XML
Konfiguration schnell erkennen was wie zusammen arbeitet. Wenn ich
Annonations verwenden würde, sähe ich dies nicht und müsste mich durch
den Code klicken um die Abhängigkeiten etc. zu erkennen.
Zum anderen kann ich die XML Konfiguration sehr schnell ändern und das
auch mit einfachsten Mitteln, bei Annotations bräuchte ich immer den
Source Code, und die Möglichkeit diesen zu kompilieren.
Welche Vorteile seht ihr denn in der Verwendung von Annotations? oder
sehe ich da etwas total falsch ? (außer der @Override und @Deprected
Annotation habe ich bisher überhaupt keinen Grund gefunden Annotations
zu verwenden :( )
JavaConfig finde ich gut, da ich es sicher für kleine AdHoc
Anwendungen verwenden kann, wo ich eben nicht die Vorteile der XML
Konfiguration benötige.
Sehr Interessant finde ich aber Spring-OSGI.
vg Matthias
ThorQue
On 22 Mai, 09:17, Gidion <exit.lu...@googlemail.com> wrote:
> Zum anderen kann ich die XML Konfiguration sehr schnell ändern und das
> auch mit einfachsten Mitteln, bei Annotations bräuchte ich immer den
> Source Code, und die Möglichkeit diesen zu kompilieren.
Diesen Aspekt finde ich auch sehr interessant. In meinem aktuellen
Projekt baue ich für Tests einen angepassten Spring-Context mittels
des SpringBuilders von Groovy auf. Wie sieht das bei Annotations aus?
Gibt es einen Mechanismus, bei dem ich die Annotations ausser Gefecht
setzte, sobald ich eine XML-Konfiguration habe?
Viele Grüsse
Thorsten
Mike Wiesner
> Gibt es einen Mechanismus, bei dem ich die Annotations ausser Gefecht
> setzte, sobald ich eine XML-Konfiguration habe?
Ja, gibt es. Die Annotations sind ja erst mal nur Meta-Daten, welche von
sich aus keine Funktion haben. Ich muss also entweder dem Application
Context mitteilen das ihr diese auswerten soll oder ich schreibe
folgendes Element in meine Spring XML-Datei:
<context:component-scan base-package="service"/>
Wahlweise kann ich die Beans auch einzeln im XML definieren, allerdings
dann ohne Konfiguration (die kommt ja durch die Annotations):
<context:annotation-config/>
<bean class="service.MeinTollerService"/>
Solange kein Element davon erscheint passiert auch nichts und ich kann
z.B. ganz normal XML (oder Java Config) machen ohne das die Annotations
eine Auswirkung haben.
Das gleich gilt natürlich bei Unit Tests bei denen ja überhaupt kein
Application Context gestartet wird. Hier haben die Annotations natürlich
auch keine Auswirkung und ich kann ganz normal im Unit Test meine
Stubs/Mocks setzen.
Grüße,
Mike
--
Mike Wiesner
Senior Consultant
Interface21 GmbH - Spring Services from the Source
Sitz der Gesellschaft: Brentanostr. 52a - D-12163 Berlin
Geschäftsführer: Steven Schuurman, Rod Johnson
Amtsgericht Charlottenburg - HRB 103773 B
Phone: +49 157 721 786 37
Oliver Schlicht
> Gibt es einen Mechanismus, bei dem ich die Annotations ausser Gefecht
> setzte, sobald ich eine XML-Konfiguration habe?
>
> Viele Grüsse
> Thorsten
Genau das ist der Punkt, den ich für gefährlich halte. Wie schnell
verbringt jemand, der nicht 100% eingewiesen ist Stunden damit sich zu
wundern, warum eine komplett andere Konfiguration geladen wird, obwohl
doch im Quellcode eine (scheinbar fixe) Konfiguration Annotiert ist.
Ich sehe ehrlich gesagt, keinen Vorteil von Annotations, der nicht
unmittelbar von dem gesteigerten Pflegeaufwand wieder aufgefressen
wird.
Gruß
Ollie
ThorQue
danke für die Antwort.
> > Gibt es einen Mechanismus, bei dem ich die Annotations ausser Gefecht
> > setzte, sobald ich eine XML-Konfiguration habe?
>
> Ja, gibt es. Die Annotations sind ja erst mal nur Meta-Daten, welche von
> sich aus keine Funktion haben. Ich muss also entweder dem Application
> Context mitteilen das ihr diese auswerten soll oder ich schreibe
> folgendes Element in meine Spring XML-Datei:
>
> <context:component-scan base-package="service"/>
>
Damit kann man eigentlich ganz gut leben. An der Stelle muss man dann
etwas mehr mit Mocks arbeiten.
Dinge wie die Datasource werden bei 2.1 weiterhin in der XML-
Konfiguration hinterlegt? Oder geht das auch über Annotations oder
einem ähnlichen Mechanismus?
Aber initial hattest du mal wegen einem denkbaren Anwendungsfall
gefragt.
Ich kann mir das schon gut vorstellen, das über Annotations zu machen.
Insbesonders wenn die von Spring betroffenen Artefakte aus Modellen
generiert werden. Da das generierte Zeug von keinem Entwickler direkt
bearbeitet wird, kann man die komplette Spring-Konfiguration über den
Generator abdecken. Somit brauchen sich die z.B. die Fachentwickler
nicht mit Spring auseinandersetzen.
Das geht mit einer herkömmlichen XML-Konfiguration bereits heute
schon. Vorteil ist, dass weniger Dateien erzeugt werden. Das bedeutet
halt kürzere Generierungszeiten, weniger Dateien im Projekt (ein
Refresh oder Clean in Eclipse ist etwas schneller).
Und was eigentlich noch ganz nett ist, wenn man sich den generierten
Code ansieht und kann direkt sehen was da konfiguriert ist, ohne eine
weitere Datei zu öffnen.
Wenn die SpringIDE das dann auch noch schön in der Outline anzeigen
und man schnell zu den betreffenden Objekten navigieren kann, ist das
dann ziemlich cool.
Wichtig finde ich halt, dass man nicht zu sehr die verschiedenen Arten
der Konfiguration mischt.
Und man braucht ein innovatives Projekt, wo man Java5 oder 6 verwenden
kann ...
Thorsten