JAX 2010: EIn Rückblick
Die JAX war auch dieses Jahr wieder eine sehr interessante Konferenz. Aus meiner Sicht gab es folgende High Lights:
- Den wie immer gut besuchten Spring Day mit vielen interessanten Talks.
- Den Spring Powerworkshop - der mittlerweile in das 5. Jahr geht und immer noch sehr viele Teilnehmer hat. Spring wird also nach wie vor in Projekten neu eingeführt.
- Spaß gemacht hat mir auch der neue Spring Advanced Workshop mit vielen Teilnehmern und vielen schönen Diskussionen. Hier freu ich mich auch schon auf die Wiederholung bei zukünftigen Konfernzen!
- Interessante Diskussionen gab es auch beim Ball-Room, mit den Kollegen und am Stand - vielen Dank dafür.
Ich möchte mich an dieser Stelle bei den Organisatoren, den Speaker (vor allem vom Spring-Day), den Besuchern und allen Kollegen für die tolle Konferenz bedanken. Es ist eine schön Bestätigung, dass die Spring-Community so aktiv ist und das Thema nach wie vor so beliebt ist. Bis zur WJAX!
Labels: JAX
Meine JAX 2010 Talks
Auch dieses Jahr habe ich wieder die Ehre, auf der JAX zu sprechen.
Ich beginne am Montag mit dem
Spring PowerWorkshop. Er führt an einem Tag in das Spring-Framework ein und geht dabei auf die Version 3.0 des Frameworks ein.
Am Dienstag gibt es dann einen ganzen Tag über Spring, den
Spring Day. Zunächst gibt uns Jürgen Höller einen Einblick in die Geschichte, aber vor allem auch die Zukunft des Spring-Frameworks. In der nächsten Session zeigen mein Kollege Mike Wiesner und ich den Umgang mit Spring Roo, einem neuen Projekt für die produktive Entwicklung mit Spring und Java. Christian Dupuis (ebenfalls SpringSource) spricht dann über die Cloud, die vor allem wegen der Akquisition von SpringSource durch VMware einen große Relevanz für uns hat. Agim Emruli gibt dann Einblicke in die Integration des Google Web Toolkits mit Spring und in der anschließenden Session zeigt Papick Garcia Taboada zusammen mit ihm, wie man mit dem SpringSource dm Server Web-Anwendungen entwickeln kann. Den Abschluss bildet Stefan Scheidt von Opitz Consulting mit einem Vortrag über die Integrationsmöglichkeiten mit Spring, der vor allem zahlreiche Beispiele aus der Praxis zeigen wird.
Dienstag abend gibt es dann den JAX Ballroom, bei dem auch ein Tisch zum Thema Spring geplant ist.
Am Mittwoch habe ich dann einen Vortrag zum Thema
Moderne Enterprise-Architekturen, bei dem es unter anderem um OSGi, Spring und dynamische Sprachen gehen wird.
Und den Abschluss bildet dann der Power Workshop
Spring Advanced. Dabei werden ich Ansätze, Patterns und Architekturen für Spring-Anwendungen zeigen, einen kurzen Einblick in neue Spring-3.0-Features geben und zum Abschluss gibt es noch eine Frage & Antwort Session - vor allem solche interaktiven Teile finde ich immer wieder interessant.
Man sieht sich dann auf der JAX - und ich hoffe auf viele spannende Diskussionen!
Labels: JAX, JAX 2010
Folien zu "8 Möglichkeiten, Projekte mit Spring zu aufzubauen"
Die Folien für meine Vortrag "8 Möglichkeiten, Projekte mit Spring zu aufzubauen" stehen nun unter
http://spring-buch.de/8Konfigurationsmoeglichkeiten.pdf zur Verfügung.
Labels: JAX
Spring Day JAX 2009
Auch dieses Jahr durfte ich wieder den Spring Day auf JAX moderieren. Der erste Vortrag war Jürgen Höllers Vortrag über Spring 3.0. Mein Kollege Agim Emruli sprach dann über Web-Architekture - gerade in diesem Bereich sind durch die Flex DS Integration in Spring und andere neue Projekte wie Spring Faces einige Bewegung. Die Präsentation über den Remoting-Support in Spring konnte Ralf Sigmund von Opitz kurzfristig übernehmen, nachdem der ursprüngliche Sprecher ausfiel. Christian Dupuis - ebenfalls bei SpringSource beschäftigt - sprach dann über das Tooling, an dem er selber maßgeblich bei der Entwicklung beteiligt ist. Hier ist mit Bundlor für OSGi-Entwicklung auch einiges in Bewegung. Ich selber habe dann über "8 Möglichkeiten für die Konfiguration von Spring-Anwendungen gesprochen". Den Abschluß bildetet die BOF, die ich eigentlich immer sehr interessant finde, um Feedback von der Community zu bekommen. Dann war es 22:30 (!) und damit der Spring Day beendet...
Labels: JAX, Spring Day
JAX 2008 - Jürgen Höller Spring 2.5 und 3.0
Es ging zunächst um Spring 2.5 mit dem Fokus auf Annotationen. Dieses Thema ist in diesem Blog schon öfter ausführlich besprochen worden. 2.5.4 und 2.5.5 kommen bis Ende Juni. Danach kommt es in den Wartungs-Modus.
Am Ende gab Jürgen dann noch einen Ausblick auf Spring 3.0:
Spring 3.0 M1 kommt im Juli.
Es gibt dann einen vollständigen REST-Support.
Es wird eine Expression Language geben, die besseren Umgang mit Spring Bean Properties usw. erlaubt. Das ist analog zu der JSF-Expression Language.
Der gesamte Kern wird auch Java 5 umgestellt, d.h. Generics, Varargs usw. werden verwendet werden. Es wird immer noch J2EE 1.4 und höher unterstützt.
Im Herbst kommt dann das Release.
Und Portlet und Servlet 3.0 wird unterstützt werden.
Web-Konversationen werden unterstützt werden.
...und Web-Formular-Wizards werden durch Annotationen unterstützt werden.
Common Attributes, Struts 1 und die alte TopLink API wird nicht mehr unterstützt.
JUnit 3.8 und traditionelle MVC Controller werden deprecated, sollten also nicht mehr verwendet werden.
Wie man sieht, bleibt also auch hier die Innovation nicht stehen. Interessant finde ich vor allem die Umstellung auf Java 5, ich denke, viele APIs werden dadurch einfacher. Und ebenfalls interessant finde ich, dass einige Features aus dem Framework entfernt werden - das bedeutet, dass das Framework auch langfristig einfach und schlank bleibt.
Labels: JAX, Jürgen Höller, Spring 3.0
JAX 2008 - Keynote Rod Johnson
Nach der Eröffnung von Sebastian Meyen hielt Rod Johnson, CEO von SpringSource, die Eröffnungskonferenz.
Es geht um die Zukunft von Enterprise Java - aber hat Enterprise Java überhaupt eine Zukunft? Man hört einige ganze Menge Dinge: Ruby on Rails ist erfolgreich, keiner benutzt Java für Web Anwendungen... Aber Rod ist natürlich nicht dieser Meinung. Er zeigt eine Grafik für die Job Trends von Ruby gegenüber Java - und Java ist mehrere Dimensionen stärker. Jobs als Metrik sind interessant, weil sie zeigen, wo die Firmen wirklich Geld investieren - das tun nicht viele Metriken. Und Technologien wie Spring wachsen auch stärker als Ruby on Rails.
Dann ging es um die wirklichen Themen: Der kalte Krieg, Monica Lewinsky und Monty Python. Aber zunächst: Warum muss Enterprise Java sich ändern? Es gibt Probleme in Bezug auf Produktivität und die Plattform ist überladen. Auch Gartner ist der Meinung, dass Enterprise sich ändern muss. Bei der Produktivität gibt es mit Ruby on Rails einen starken Gegner. Das Problem ist dabei, das einfache Lösungen für einfache Probleme nicht im Java-Bereich nicht vorhanden sind - es gibt nur (einfache) Lösungen für komplexe Probleme.
Als J2EE entworfen wurde, war Clinton Präsident und Monica Lewinsky war sein Problem - wahrscheinlich gibt es bald wieder einen Präsident Clinton. In Deutschland war Kohl Kanzler. Es ist also schlicht alt. Und über die Zeit sammelt sich halt einiges an. Java EE 6 versucht, einige dieser alten Dinge aus der Spec zu entfernen. Rods Meinung nach ist das ein sehr wesentlicher Schritt, die erste ernsthafte Renovierung in den letzten 10 Jahren. Java EE 6 will die Open Source Frameworks unterstützen, die sehr relevant geworden sind. Und vor allem führt Java EE 6 Profiles ein. Dies sind bestimmte Subsets der Gesamtplattform, die typische Nutzungsprofile abdecken. Profile A ist im wesentlichen ein einfacher Web Server (+ JSR 45 Debugging API und JSR 250 Common Annotations). In Servlet 3.0 (einem Teil von Java EE 6) gibt es eine Möglichkeit, Servlets zur Laufzeit zu registrieren. Profile B enthält dann EJB 3.1 light, JTA 1.1, JPA 2.0, JSF 2.0 und wahrscheinlich Web Bean 1.0. EJB 3.1 light ist leider noch nicht wirklich definiert und es gibt hier natürlich das Problem, dass es zwei Komponenten-Modelle gibt, nämlich EJB 3.1 und Web Beans 1.0. Und Profile C ist dann die vollständige Plattform. Damit ist dieses Profile C wie die Titan Atomrakete aus dem kalten Krieg.
Durch diese einfacheren Plattformen ist es nun auch möglich, neue Server-Implementierungen zu etablieren, weil die Einstiegsschwelle so hoch ist. Zur Zeit von Monica Lewinsky gab es mehr Application Server Hersteller als Praktikantinnen - heute gibt es im wesentlichen IBM und Oracle/BEA. Und für diese Anbieter ist ein Teil einer größeren Plattform. Und damit sind sie nur ein Teil einer Gesamtlösung und möglicherweise wichtiger als Basis für ihre Standardsoftware, also gibt es dort einen anderen Fokus als den Application Server selbst und seine technische Qualität. Und interessanterweise ist es so, dass Tomcat wesentlich stärker ist als IBM oder Oracle/BEA. Es ist also der eigentliche Markt-Führer.
Also was wird passieren:
Es wird wieder echten Wettbewerb im Application Server Markt geben. Und zwar vor allem im Bereich der Profile A und B.
Der wirtschaftliche Wert wird sich eher an dem orientieren, was die Leute wirklich nutzen. Das bedeutet, dass die Palttformen mit den meisten Nutzern wertvoller werden.
Die zukünftigen Application Server werden auf OSGi basieren und modular und leichtgewichtig sein.
Die zukünftigen Application Server werden nicht nur die JCP Spezifikation implementieren. Es gibt weitere Quellen für relevante Standards.
Enterprise Java ist nicht mehr ein Ein-Parteien-Staat. Neben dem JCP gibt es OASIS (SCA, Web Services), OSGi und Open Source Projekte (z.B. aus der Eclipse Foundation).
Der JCP wird eher durch Open-Source-Projekte gesteuert werden. Sun ist schließlich auch auf dem Weg zu einer Open-Source-Firma.
Der Markt wird die Lücke zwischen Tomcat und WebLogic/WebSphere füllen. Dabei geht es um APIs und auch um die Betriebs-Aspekte.
Die Lücke zwischen ESBs und Application Server wird gefüllt werden. SOA ist dafür zu neu und relevant.
Der dunkle Ritter (Monty Python) wird besiegt. EJB ist - und das kann man durch Job-Trends nachweisen - das COBOL im Enterprise-Java-Bereich.
Zusammenfassend sind wir also in einer Zeit sehr schneller Änderungen. Java EE 6 wird sicher wichtig werden, so auch OSGi - und es wird spannend!
Labels: JAX, Keynote, Rod Johnson
JAX 2008
Auch dieses Jahr bin ich wieder bei der JAX - mittlerweile gibt es sie seit 2001 und jedes Jahr wird sie größer. Dieses Jahr gibt es 2000 Teilnehmer (!) und 178 Speaker. Ich habe den Spring Day mit organisiert und dr ist schon in vollem Gange (ich sitze gerade in Jürgen Höller's Session). Es gibt wieder viel neues und interessantes....
Labels: JAX, Spring Day
Fazit des Spring Days
Montag ist der Spring-Day gewesen, der mittlerweile ein fester Bestandteil der JAX-Konferenz ist. Ziel war es, den Besuchern sowohl etwas über die neuen Technologien wie Spring-OSGi, Acegi und Spring 2.1 mitzuteilen, wie auch über die Architekturen, die man mit Spring typischerweise implementiert. Das Interesse des Publikums war gewohnt groß und es gab einige interessante Vorträge. Auch in der Hauptkonferenz waren noch einige Spring-Vorträge - unter anderem auch von mir - doch dazu später mehr.
Labels: JAX, Spring, Spring Day
JAX Spring Day - Spring und MDA - Gegensatz oder Ergänzung? - Peter Friese, Jürgen Höller
Diese Session ist ein Art Show-Down: Welcher Ansatz ist besser? Zunächst gab es ein Problem-Statement. Es gibt komplexe Systeme, komplexe Technologien, komplexe Anforderungen und den bekannten hohen Zeit- und Kostendruck. Also ist das Problem vor allem die Komplexität.
Zur Lösung kann man die Technologie vereinfachen. Dadurch soll wieder die Konzentration auf die Fachlichkeit möglich sein. Beispiele dafür sind Vereinfachungen wie Hibernate vs. EJB 2.x CMP / BMP. Andere Möglichkeiten sind Ruby on Rails oder Grails. Oder eben harmonisierende (Meta-)Frameworks wie Spring oder Keel. Die andere Möglichkeit ist die Anhebung des Abstraktionsgrads durch Model Driven Software Development.
Jürgen übernahm dann die Darstellung der Spring-Position. Es soll höhere Produktivität durch die Konzentration auf das Wesentliche ermöglichen und klare Strukturen des Anwendungscodes durch Separation of Concerns ermöglichen. Dadurch ist der Anwendungscode "natürlich" testbar und man kann den Anwendungscode von der konkreten Laufzeitplattform entkoppeln. Zu den Lösungsansätzen von Spring gehört Dependency Injection und AOP. Dadurch kann man Separation of Concerns sowohl in Architektur als auch im Code erreichen. Spring abstrahiert von dnr konkreten Runtime-Services zum Beispiel beim Transaktions-Handling und Drittprojekte wie Hibernate sind konsistent integriert. Der manuell zu erstellende Code wird minimalisiert - durch unchecked Exceptions oder Templates.
An der Stelle habe ich dann den Stand von Interface21 aufgebaut und ich kam zurück, als Peter Friese zeigte, wie man modellgetrieben eine Anwendung bauen kann. So kann man in UML Abhängigkeiten zwischen Services modellieren, die dann durch Springs Dependency Injection miteinander verdrahtet werden.
Abschließend die Bewertung: Bei MDSD gibt es eine homogene, vorgegebene Architektur. Die Entwickler müssen nicht alle Aspekte von Spring in- und auswendig kennen. Dadurch entsteht höhere Produktivität.
Bei "Spring Pur" steht der Code im Mittelpunkt. Der Java-Source-Code ist das zentrale Artefakt. Eingehende Kenntnisse sind notwendig. Auf der anderen Seite ist man agiler: Man kann leichter refactoren.
Letztendlich ist es auch ein Kultur. Die Entwickler kommen mit den Modellen zurecht - oder eben nicht. Und Jürgen entwickelt Code-zentriert - was für einen Framework-Entwickler wohl eher typisch ist. Und mit Spring ist es möglich, sehr leicht auch code-zentiert Anwendungen zu entwickeln. Aber auf der anderen Seite ist Konsistenz auf diese Weise schwer zu erreichen. Durch ein MDSD-Vorgehen ist das leichter erreichbar.
Labels: JAX, mdsd, Spring, Spring Day
JAX Spring Day - Spring OSGi - Martin Lippert, Gerd Wütherich, Bernd Kolb
Dieser Vortrag hat - nicht ganz zu unrecht - den Untertitel "Plattform der Zukunft". Er beginnt mit einer Einführung in OSGi. OSGi ist ein dynamisches Modul-System für Java. Ein Modul (genannt Bundle) besteht aus mehreren Packages. Es gibt Abhängigkeiten zwischen den Modulen und Module können versioniert sein. Außerdem kann man bestimmte Teile der Bundles (public API) exportieren und damit die Sichtbarkeiten einschränken. So kann man zum Beispiel die Implementierungs-Klassen verbergen und nur die Interfaces exportieren. Dadurch kann man das Chaos, das sonst im Classpath leicht herrscht, lösen.
Module können dynamisch zur Laufzeit installiert, gestartet, gestoppt, deinstalliert und aktualisiert werden. Dadurch gibt es natürlich Probleme, wenn man zum falschen Zeitpunkt auf ein Modul zugreift, zum Beispiel wenn es deinstalliert ist.
OSGi definiert außerdem Services. Bundles können die Services veröffentlichen oder ihn verwenden. Die Services können zur Laufzeit kommen und gehen.
OSGi wird seit 1999 von der OSGi-Alliance betreut. Es hat seinen Fokus auf Leichtgewichtigkeit und Dynamik. Es war früher für Embedded Systeme gedacht, mittlerweile wird es auch für Client- und Server-Systeme genutzt. Es gibt verschiedene Implementierung, so Eclipse Equinox, Apache Felix, Knopflerfish, ProSyst mBedded Server Equinox Edition. Kommerzielle Implementierung gibt es von ProSyst und Knopflerfish Pro.
OSGi wird heute schon bei Eclipse genutzt, bei Server-Side Eclipse und bei eRCP. IBM nutzt es bei WebSphere Application Server 6.1, beim Lotus Notes Client und bei Jazz (Team-Kollaborations-Unterstützung für Eclipse). BEA und Oracle sind interessiert. JBoss hat einen Prototyp für eine OSGi-Umstellung. Und auch Adobe baut an solchen Sachen. Außerdem gibt es einen JSR, der OSGi in der Java-7-Plattform integrieren will.
Spring-OSGi ist eine Brücke zwischen Spring und OSGi. Spring-Anwendungen können dann mit OSGi implementiert werden. Es unterstützt Equinox, Felix und Knopflerfish. Dabei soll man die dynamischen Features von OSGi nutzen können. Spring selber muss man dann auch in OSGi-Bundles aufteilen.
Dabei darf sich die Komplexität nicht erhöhen, es sollte beim POJO-Programmiermodell bleiben. Außerdem muss das OSGi-Service-Modell integriert werden: Spring-Beans sollten zu Services werden können und umgekehrt. Und Testing außerhalb des OSGi-Containers muss natürlich auch möglich sein. Und man muss natürlich auch alle anderen Spring-Features nutzen können.
Bundles haben dabei jeweils einen eigenen ApplicationContext. Der wird von Spring-OSGi beim Aktivieren des Bundles automatisch erzeugt und beim Deaktivieren zerstört. Die Konfiguration liegt im Bundle (einem JAR oder Verzeichnis) im Unterverzeichnis META-INF/spring. Die Spring-Beans können mit dem osgi-XML-Namespace als OSGi-Service exportiert werden und die Services können auch in Spring importiert werden. Dadurch kann man den eigenen Code - schon fast traditionell bei Spring - von der OSGi-API unabhängig halten. Außerdem kann man so "public" Spring-Beans, die als OSGi-Services exportiert werden, und "private" Spring-Beans definieren.
Da OSGi dynamisch ist, kann man mit einem Service-Listener auf das Hoch- oder Runterfahren eines Services reagieren. Und auch Zugriff auf Properties aus einem OSGi-Bundle oder Zugriffe auf Bundles sind machbar.
Es schloss sich ein Beispiel an. Ein OSGi-Bundle ist ein Order-Service, der andere ein Customer-Service. Die haben beide ein einfaches Java-Interface als Schnittstelle. Man kann sie auf der OSGi-Konsole installieren, starten, monitoren usw. Und man kann natürlich die Implementierung zur Laufzeit gegen eine andere austauschen. Die Bundles kann man auch über das Internet herunterladen.
Spring-OSGi 1.0M1 wurde am 5.4.2007 veröffentlicht. Es enthält den osgi-XML-Namespace. Es unterstützt auch die Integrations-Tests. Es fehlt Unterstützung für Web-Anwendungen und es gibt einige Probleme mit ClassPath-Problemen. Das Release soll dann zusammen mit Spring 2.1 kommen.
Man kann mit Spring-OSGi Standalone-Server-Applikatione bauen. Er läuft dann auf Basis von OSGi und kann Jetty als Http-Service und Servlet-Container enthalten. Oder man deployt OSGi als Teil des WARs. Eine Servlet-Bridge sorgt dann dafür, dass Requests an die "richtigen" Bundles weitergeleitet werden.
In beiden Fällen werdne die Anwendungen aus Bundles zusammengesetzt. Spring kann inklusive Remoting usw. genutzt werden. Auch auf dem Client (Eclipse RCP) kann man Spring verwenden. Also zum Beispiel kann man dann Dependency Injection für die Extension Points verwenden und damit Views injecten.
In einem aktuellen Projekt benutzten sie Equinox in einem produktiven System. Der Client basiert auf Eclipse-RCP und Spring. Der Server nutzt Spring und OSGi innerhalb von Tomcat.
Labels: JAX, Spring, Spring Day, Spring-OSGi
JAX Spring Day - Spring 2.1 - Jürgen Höller
Als ersten Speaker auf dem Spring Day kam Jürgen Höller zu Wort, seines Zeichens distinguished Engineer und Spring Chef-Entwickler.
Spring 2.1 wird Java 6 und Java EE 5 unterstützen. Es wird kein JDK 1.3 Support mehr haben - die letzten beiden Releases werden unterstützt. Zu JDK 1.6 wird zum Beispiel JDBC 4.0 unterstützt und JSR-223 (Rhino-Scripting). Andere Spring Releases unterstützen schon JDK 1.6.
Spring 2.1 unterstützt Java EE 5 z.B. EJB 3, JTA 1.1, Java Mail 1.4 etc. Ältere Releases unterstützen auch schon JSR 250 (@PostConstruct, @PreDestroy, @Resource). @Resource weißt auf einen Spring-Bean nach Namen oder JNDI.
Bei den Annotationen wird dann auch Autowiring unterstützt (@Autowired). Dazu muss man autowire="annotation" in die Konfiguration schreiben. Dadurch soll Autowiring by Type attraktiver werden, weil man es durch die Annotation besser konfigurieren kann.
@Required zur Markierung benötigter Abhängigkeiten ist jetzt durch depdency-check="annotation" oder default-dependency-check="annotation" konfigurierbar.
Weitere Annotationen werden möglicherweise später auch unterstützt. Und Jürgen reagiert hier auch gerne noch auf Input.
Spring unterstützt jetzt auch Aspectj-Loadtime-Weaving. Das nutzt auch die LoadTimeWeaver wie JPA, dadurch kann man es in einem ApplicationContext einfach aktivieren. Außerdem gibt es auch das beanName-Pointcut-Element für Aspect-Pointcut-Ausdrücke. Dabei werden die Beans durch den Namen des Spring-Beans ausgewählt. Dadurch kann man zum Beispiel mit bestimmten Spring-Bean-Namen bestimmte Pointcuts aktivieren. Dadurch kann man nun wirklich sehr leicht zwischen Spring AOP und AspectJ wählen.
Nächstes Thema ist JMS. In Spring 2.0.3 wurde z.B. für den DefaultMessageListenerContainer die maxConcurrentConsumers-Eigenschaft eingebaut, um die Anzahl der gleichzeitigen Consumer begrenzt. Im Spring 2.1 kommt nun auch Unterstützung für JCA 1.5. Dadurch kann man den JCA-Adapter, den es zum Beispiel auch für JMS-Provider gibt, im Spring ApplicationContext laufen lassen. Auch ein ApplicationContext kann jetzt ein JCA Resource Adapter werden. Das kann dann mit JMX gemanaged werden und man kann dort recht viel machen - die JDO Integration in J2EE lief ja auch über JCA.
Spring 2.1 hat den JPA-Support noch etwas verfeinert. Jetzt wird TopLink, Hibernate, Open JPA unterstützt und bestimmte Erweiterungen wie flush mode='never' werden einheitlich unterstützt. Die JPA-Implementierung bieten zwar alle diese Erweiterungen an, aber eben jeweils mit unterschiedlicher API oder Konfiguration. Spring vereinheitlicht das.
Außerdem wird die WebSphere-proprietäre Transaktions-API unterstützt. Dazu zählt zum Beispiel auch die Unterbrechung (Suspension) von Transaktionen. Die dabei verwendete API ist die offizielle von IBM freigegebene.
Eine wesentliche Innovation in Spring 2.0 waren die XML-Namespaces. In Spring 2.1 kommt ein jms-Namespace hinzu, der die Konfiguration der MessageListenerContainer ermöglicht. Möglicherweise gibt es in 2.1 auch ein jpa- und ein web-Namespace, der vielleicht aber auch erst in Spring 2.2 kommt.
Labels: Interface21, JAX, Jürgen Höller, Spring, Spring 2.1, Spring Day
J for Java |
I for Internet, iMac, iPod and iPad |
Me for me
