Catégorie: Spring

Bonjour à tous,

Soirée Spring 3.1 le 23 février 2012 avec Gildas Cuisinier

A propos de Gildas Cuisinier :
Gildas Cuisinier, consultant au Luxembourg, est connu pour son activité pour la communauté Spring francophone. Il est à l'origine de la section Spring de Developpez.com laquelle comprend forum, blog, cours, articles techniques, interview et FAQ.

Il a également participé à la relecture de plusieurs ouvrages sur Spring (Spring par la pratique et Spring Dynamic Modules in Action) et s'est engagé dans l'évangélisation de Spring 3.0 par le biais de conférences dans plusieurs JUG en France et au Luxembourg. Il a également apporté la base du support de XMPP/Jabber de Spring WebServices.

En dehors du monde Spring, il a également collaboré avec Henri Gomez pour fournir un packaging d'OpenJDK pour Mac OS X.

A propos de l'intervention
Spring est mort, longue vie à Spring !

Cette session présente les nouveautés apportées par Spring Framework 3.1 pour simplifier les développements d'applications d'entreprises en Java en tirant profit des nouveautés de JEE 6 !

Spring, mais sans une dose de XML !

Il vous sera également présenté comment créer des livrables déployables sur plusieurs environnements (dev, test, prod par exemple) sans modification de l'artéfact.

Nous nous réunirons à :
Technopôle Marseille Provence
Château Gombert
Les Baronnies, Bâtiment B, RDC
Rue Paul Langevin
13013 MARSEILLE

(le bâtiment rouge que l'on aperçoit ici)

N'hésitez donc pas à venir nombreux le Jeudi 23 février 2012 à 19h30

Comment puis-je ne rien rater du MarsJUG ?
Vous pouvez suivre son twitter

Merci de vous inscrire à cette conférence et à la mailing list

Pourquoi venir au MarsJUG ?
Comme tous les JUGs le MarsJug permet de rester à la pointe de ce qui se fait en Java en participant à des conférences et rencontrer des speakers reconnus dans le monde.
Vous pouvez venir par curiosité pour découvrir les JUGs, par amour des JUGs parce que vous êtes habitués, pour vous tenir au courant de se qui se fait de nouveau ou alors pour boire un coup avec nous après le JUG

A quelle fréquence le JUG se réunira ?
Un moyenne tous les mois et demi

à bientôt,
Alain Defrance.

Problème

Sur certains projets, j'ai eu l'occasion de voir des fichiers de configuration Spring de ce type :

<import resource="monitoring-environnement1.xml"/> 
<import resource="monitoring-environnement2.xml"/> 
<import resource="monitoring-environnement3.xml"/>

Et bien évidemment, chacun des fichiers de configurations importés était tous semblables, avec comme seule différence les noms de beans Spring ou des valeurs de propriétés.
Si demain, un nouvel environnement devait être ajouté, je vous le donne dans le mille : un copier / coller, un s/environnement1/nouvel-environnement/g !

Même si cela fonctionne bien, ce n'est pas la solution la plus propre : Si le système de monitoring devait être modifié, il faudrait éditer X fichiers, avec le risque d'oublier un fichier, ou un valeur...

Solution 1 : Créer un namepace dédié au monitoring

Une première solution possible serait de remplacer ces imports par un namespace dédié au monitoring. Il suffirait dès lors d'utiliser une configuration de ce type :

<monitoring:environnement name="environnement1"/> 
<monitoring:environnement name="environnement2"/>

C'est déjà beaucoup plus propre, mais cette solution n'est pas des plus pratiques :

La configuration "générique" sera réalisée via une API spécifique à Spring, que peu de développeurs connaissent ( BeanDefinitionParser, ParserContext, BeanDefinitionRegistry, ..), ce qui rends toute modification assez complexe
Le namespace sera dédié au monitoring ! Si le domaine des fichiers était tout autre, il faudrait développer un nouveau namespace.
Le namespace va cacher aux utilisateurs les beans réellement instanciés.
Bref, c'est déjà mieux mais pas encore suffisamment claire et simple.

Solution 2 : Créer un namepace d'importation de modèles de configuration

Afin de répondre à ces problématique, il est possible de créer un namespace beaucoup plus générique. Celui qui permettrait d'importer une configuration classique (un modèle), mais en remplaçant certaines variables par des valeurs.

Le modèle serait un fichier de configuration Spring tout à fait compréhensible par des habitués de Spring, mais dans laquelle des variables seraient définies :

<beans xmlns="http://www.springframework.org/schema/beans" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">  
 
  <bean name="scheduledTimeTask.${environnement}" class="org.springframework.scheduling.timer.ScheduledTimerTask"> 
  <property name="timerTask" ref="monitoringTask.${environnement}"/>  
 
  <property name="delay" value="1000"/> 
  <property name="period" value="1000"/> 
  </bean> 
  <bean name="timer.${environnement}" class="org.springframework.scheduling.timer.TimerFactoryBean"> 
  <property name="scheduledTimerTasks"> 
  <list> 
  <ref bean="scheduledTimeTask.${environnement}"/> 
  </list> 
  </property> 
  </bean> 
  <bean name="monitoringTask.${environnement}" class="be.hikage.springtemplate.MonitoringTimerTask"> 
  <property name="url" value="${${environnement}.url}"/> 
  </bean>  
 
</beans>

Ici, ${environnement}, est une variable qui sera définie lors de l'importation du modèle :

 
<hikage:import-template location="template-monitoring.xml"> 
  <hikage:variable name="environnement" value="environnement1"/> 
</hikage:import-template>

Conclusion

Cette solution possède donc plusieurs avantages :

En cas de modification du modèle, un seul fichier devra être modifié.
Le namespace pourra être utilisé pour différent domaine ( monotoring, etc .. )
Le modèle sera modifiable par n'importe quel développeur connaissant Spring, et tout à fait lisible

Informations

Ce projet est disponible sous licence Apache 2 sur http://code.google.com/p/spring-import-template/

Le lundi 08 mars se tiendra le premier événement de l'année 2010 du YaJUG. Comme d'habitude, la conférence se tiendra au CRP Henri Tudor (29, avenue John F. Kennedy L-1855 Luxembourg - Kirchberg). Agenda:

• 17h30 - Welcome & registration
  
  
• 17h45 - Oracle plans for Java and communities, Sébastien Stormacq
  
  
• 17h55 - Eclipse - an Open Source Innovation Network, Ralph Mueller
  Open Source- for many the expression is a synonym for 'no cost' or 'easy to obtain'. Only known to the insider is the fact that Open Source methods and licenses have become the basis of many industry collaboration efforts. Here Open Source is applied to jointly develop, maintain and distribute software relevant for the industry. Due to its well-defined Intellectual Property Management and its Development Process is the Eclipse Project today well positioned to support industry initiatives in the collaborative value creation process. The commerce-friendly Eclipse Public License (EPL) makes it easy to capture value in commercial exploitation, providing the basis for a successful and sustainable eco system. The talk will discover the motivation for open source in its different instantiations, discuss an 'open source maturity model' and will explain the Eclipse Foundation in more detail. We will also look into the future trends that we experience in the Eclipse Eco System.
  
  
• 18h20 - e4: building the next generation of the Eclipse Platform, Frédéric Conrotte
  
  
• 18h50 - OSGI in a nutshell, Pierre-Antoine Grégoire
  Swift presentation of OSGi and derived technologies, followed by a series of demos allowing to demystify its supposed complexity.
  
  
• 19h20 - Spring dmServer, Christopher Frost
  Virgo is a modular open source application server based on OSGi. It supports standard WAR files and modular webapps comprising OSGi bundles. We'll explore Virgo features such as: repositories, deployment plans, regions, admin shell, and the admin console. The session will discuss the increasingly open future direction for the project and how you can get involved. This will be followed by a demo of a simple modular application showing it in both the command line shell and the web console of Virgo.
  
  
• 17h30 - Welcome & registration
  
  
• 20h05 - Networking cocktail

Gratuit pour les membres YaJUG, les étudiants et les personnes sans-emploi. Vous devez cependant vous inscrire.

Plus d'informations sur le site du YaJUG !

• Le site du Java User Group de Luxembourg (YaJUG)

Bonjour à tous,

Comme promis une seconde session au MarsJUG est prévue pour le mois de Février.
Après la venue de Didier Girard qui nous a présenté les technologies Google (voir les photos), c'est avec Spring que le JUG continuera sa route en compagnie de Gildas Cuisinier.

Actuellement consultant au Luxembourg, est plus connu pour son activité pour la communauté Spring francophone. Il est à l'origine de la section Spring de Developpez.com (http://spring.developpez.com) laquelle comprend forum, blog, cours, articles techniques, interview et FAQ.
Plus récemment, il a été relecteur de la seconde édition de "Spring par la pratique"

Au cours de sa présentation il abordera les sujets suivants :

• Historique
• L'hiver : EJB
• Spring, ses concepts (IoC, AOP)
• Historique des versions
• Spring 3.0
• Compatibilité et changements
• Support de REST
• Expression Language
• Autres nouveautés : Scheduling, namespaces, JSR 330, JSR 303, ..
• Spring 3.0 et JEE 6

Cette nouvelle soirée JUG aura lieu le 18 février dans les locaux de la société ViaXsoft pour la seconde fois (encore merci) à l'adresse suivante :

Technopôle Marseille Provence
Château Gombert
Hotel Technologique (salle Mozart)
45 rue Frédéric Joliot Curie
13013 MARSEILLE"

N'hésitez donc pas à venir nombreux le jeudi 18 février à 19h.

Comment puis-je ne rien rater du MarsJUG ?
Vous pouvez suivre son twitter
Suivre les évenement sur le site

N'hésitez pas à vous inscrire à nos conférences et à la mailing list

Pourquoi venir au MarsJUG ?
Comme tous les JUGs le MarsJug permet de rester à la pointe de ce qui se fait en Java en participant à des conférences et rencontrer des speakers reconnus dans le monde.
Vous pouvez venir par curiosité pour découvrir les JUGs, par amour des JUGs parce que vous êtes habitués, pour vous tenir au courant de se qui se fait de nouveau ou alors pour boire un coup avec nous après le JUG

A quelle fréquence le JUG se réunira ?
Un jeudi tous les mois ! (dans la mesure du possible)

à bientôt,
Alain Defrance.

Vous pouvez trouver ce billet sur mon nouveau blog avec les informations mises a jour.

Dans le billet précédant [step4] nous avons utilisé le registre de services OSGi pour consommer/fournir le service UserService. Nous avons montré que l'utilisation du registre de services OSGI, permettait de rendre opérationnel le lancement/arrêt du bundle org.akrogen.gestcv.services qui fournit le service UserService :

• lorsque le bundle service org.akrogen.gestcv.services est arrêté, le bundle client org.akrogen.gestcv.simpleosgiclient qui souhaite consommer le service UserService, récupère une instance null.
  
• lorsque le bundle service org.akrogen.gestcv.services est lancé, le bundle client org.akrogen.gestcv.simpleosgiclient qui souhaite consommer le service UserService, récupère l'instance UserService fournit par le bundle services.
  

Dans ce billet je vais expliquer 2 "bonnes pratiques" à suivre dans les Bundle OSGi :

• scinder les bundles services en 2 bundles services API et Implémentation. Dans notre cas nous scinderons le bundle org.akrogen.gestcv.services en 2 bundles services API et Implémentation.
  
• favoriser la gestion des dépendances entre bundles avec Import Package au lieu de Require Bundle, qui sera expliqué plus en détail dans la section Import Package.
  

Voici un schéma de ce que nous allons effectuer dans ce billet :

Ce schéma montre que :

• le bundle service org.akrogen.gestcv.services est scindé en 2 bundles service API et Implémentation.
• les dépendances entres bundles sont gérées via Import Package (et plus par Require Bundle).
  

» Lire la suite!

Vous pouvez trouver ce billet sur mon nouveau blog avec les informations mises a jour.

Dans le billet précédant [step3] nous avons mis en place les 3 bundles OSGi Client org.akrogen.gestcv.simpleosgiclient, Services org.akrogen.gestcv.services et Domain org.akrogen.gestcv.domain. Le service UserService est récupéré via la factory de services ServicesFactory qui est un singleton. OSGi met en avant le fait que l'on puisse lancer/stopper des bundles à chaud sans devoir arrêter le conteneur OSGi. Nous verrons dans ce billet que le lancement/arrêt de nos bundles est à ce stade obsolète et par la suite comment y remédier en utilisant le registre de services OSGi. Autrement dit ce billet aborde le registre de services OSGi en expliquant comment fournir/consommer le service UserService via ce registre. Je vous conseille de lire La plate-forme dynamique de services OSGi pour plus d'informations sur la notion de services OSGi.

Voici un schéma de ce que nous allons effectuer dans ce billet :

Ce schéma montre que :

• le bundle client org.akrogen.gestcv.simpleosgiclient consomme toutes les 5 sec le services UserService via la Thread FindAllUsersThread.
• la factory de services ServicesFactory a disparu. L'instance service UserServive est enregistré et récupéré via le registre de services OSGi (en utilisant ServiceTracker).

Dans ce billet nous montrerons pas à pas comment nous arrivons au choix de conception décrit ci-dessus :

• Dans la section start/stop bundle, le bundle client appele via une Thread toutes les 5 sec le service UserService via la factory ServicesFactory. Nous montrerons qu'avec le singleton ServicesFactory, l'arrêt du bundle services est obsolète. Vous pouvez télécharger l'ensemble des projets expliqués dans cette section sur org.akrogen.gestcv_step4-thread.zip.
  
• Dans la section OSGi Services Registry, le bundle service et client utilisent le registre de services OSGi pour fournir/consommer le service UserService. Nous montrerons qu'avec l'utilisation du registre de services OSGi, l'arrêt du bundle service a une influence. Vous pouvez télécharger l'ensemble des projets expliqués dans cette section sur org.akrogen.gestcv_step4-osgiservicesregistry.zip.
  
• Dans la section ServiceTracker, le ServiceTracker OSGi est utilisé dans le bundle client pour consommer le service UserService enregistré (par le bundle service) dans le registre de services OSGi. Ce tracker évite de solliciter tout le temps le registre de services OSGi pour récupérer le service UserService. Vous pouvez télécharger l'ensemble des projets expliqués dans cette section sur org.akrogen.gestcv_step4-servicetracker.zip.
  

» Lire la suite!

Le 09 novembre prochain, le CRP Tudor accueillera une conférence YaJUG sur le thème "Spring 3.0 : What's up ?". Agenda:

• 18h00 - Welcome & registration
  
• 18h15 - Spring 3.0 : quoi de neuf ? , Gildas Cuisinier (Developpez.com)
  Spring Framework n'est maintenant plus à présenter, il est de plus en plus présent dans les applications Java en entreprise. Si à l'origine, sa configuration était particulièrement verbeuse, au gré des nouvelles versions, celle-ci s'est fortement simplifiée, grâce à l'introduction des namespaces dédiés et dernièrement grâce au support des annotations. Parallèlement, le nombre de frameworks et outils tiers supportés n'a lui cessé d'augmenter. Mais alors, que nous apportera Spring 3.0 ?.
  
• 19h45 - Java puzzler
  Testez vos connaissance sur le langage de programmation Java et gagnez des T-Shirts, des livres etc ...
  
• 20h00 - Drink offered by Kitry Consulting S.A. -

Gratuit pour les membres YaJUG, les étudiants et les personnes sans-emploi. Vous devez cependant vous inscrire.

La conférence ce tiendra dans les locaux du CRP Henri Tudor, à Kirchberg. Plus d'informations sur le site du YaJUG !

• Le site du Java User Group de Luxembourg (YaJUG)

Comme vous le savez peut-être l'internationalisation à base de ResourceBundle ne supporte que des fichiers .properties encodé en ISO-8859-1, il faut donc encoder les caractères spéciaux sous la forme \uxxx ce qui n'est pas très lisible lorsque vous utilisez des languages comme l'arabe ou le chinois. De plus, si vous voulez ou devez utiliser des fichiers .properties encodés en UTF-8 vous êtes bloqués dès que vous devez utiliser des caractères spéciaux.

Une première solution est de passer par des fichiers XML en spécifiant l'encodage UTF-8.

Néanmoins, Spring propose une solution avec la classe ReloadableResourceBundleMessageSource. En effet, avec cette classe on peut spécifier l'encodage utilisé pour les fichiers directement dans le mesageSource. En plus de cela, cette classe suppporte également le rechargement des fichiers properties soit à intervalle régulier soit en utilisant la méthode clearCache().

Il faut faire attention en passant à cette classe que les liens vers le(s) basename(s) se fait en utilisant des ressources Spring, donc en suivant la nomenclature de ces dernières.

Voici un exemple d'utilisation avec Spring :

<bean id="messageSource" class="org.springframework.context.support.ReloadableResourceBundleMessageSource"> 
   <property name="basenames"> 
      <list> 
        <value>classpath:org/project/i18n/messages</value> 
        <value>classpath:org/project/i18n/errors</value> 
     </list> 
   </property> 
   <property name="cacheSeconds" value="-1" /> 
   <property name="fileEncodings" value="UTF-8" /> 
   <property name="defaultEncoding" value="UTF-8" /> 
</bean>

Mettre cacheSeconds à -1 permet d'indiquer de ne pas chercher à recharger les fichiers .properties.

Vous pouvez trouver ce billet sur mon nouveau blog avec les informations mises a jour.

Dans le billet précédant [step2] nous avons créé le Bundle OSGi org.akrogen.gestcv.domain et préparé l'environnement OSGi (Target Platform). Dans ce billet nous allons créer les 2 Bundles OSGi Services org.akrogen.gestcv.services, et Client org.akrogen.gestcv.simpleosgiclient et gérer leur dépendances via leur fichier MANIFEST.MF.

Voici un schéma de ce que nous allons effectuer dans ce billet :

Ce schéma met en évidence plusieurs notions :

• les dépendances entre les Bundle OSGi s'effectuent via le fichier META-INF/MANIFEST.MF et plus par le Java Build Path classique.
• l'appel des services par le client ne se fait plus par un main Java mais par la méthode start du BundleActivator.

En fin du billet nous reprendrons les 2 problèmes souléves avec le Java build Path classique et qui seront résolus avec OSGi:

• Classes non protégées qui sera résolu via les export package du MANIFEST.MF.
  
• ClassLoader qui sera résolu par la fait qu'un Bundle OSGi a son propre ClassLoader.
  

Vous pouvez télécharger les projets org.akrogen.gestcv_step3.zip et org.akrogen.gestcv_step3-commons-lang.zip (zip qui contient les Bundle OSGi qui utilisent 2 versions de la librairie Apache commans-lang*.jar et qui montre en évidence le problème de ClassLoader résolu) présentés dans ce billet.

» Lire la suite!

Vous pouvez trouver ce billet sur mon nouveau blog avec les informations mises a jour.

Dans le billet précédant [step0], j'ai présenté ce que je souhaitais effectuer dans les billets intitulés Conception d'un client Eclipse RCP et serveur OSGI avec Spring DM. Pour rappel, mon idée est d'expliquer pas à pas comment créer une application cliente eclipse RCP qui communiquera avec des services hébérgés sur un serveur OSGI. L'application RCP affichera une liste d'utilisateurs User récupérée via un service UserService qui sera hébérgé sur le serveur OSGI. Dans ce billet nous n'allons pas encore faire d'OSGI, mais nous allons créer un client (Java main) qui va communiquer avec un service UserService qui retournera une liste de User. Ce service qui est une interface sera récupéré via une factory de services ServicesFactory. Nous découperons chacune de ces couches (Client/Service/Domain (POJO User)) dans un projet Java distinct.

Voici un schéma de ce que nous allons effectuer dans ce billet :

Ce schéma met en évidence trois projets Java :

• org.akrogen.gestcv.domain (POJO) : projet Java qui contient les POJO (domaine de l'application) entre autres le POJO User.
• org.akrogen.gestcv.services (Services) : projet Java qui contient le service UserService qui permet de retourner une liste d'utilisateurs User.
• org.akrogen.gestcv.simplemainclient (Client) : projet Java qui consomme dans un main Java le service UserService.

Les dépendances entre les projets sont gérées classiquement via le Java Build Path du projet. Nous verrons en fin de ce billet les 2 problémes courant que nous rencontrons avec ce type de dépendance classique :

• il est impossible de rendre inaccéssible l'utilisation de certaines classes d'un projet Java aux classes d'un autre projet Java. Ce problème sera résolu via OSGI dans le prochain billet en indiquant les packages que l'on souhaite exposer.
• tous les projets Java partagent le même ClassLoader, ce qui peut poser des problèmes lorsque l'on souhaite utiliser des versions différentes d'une librairie dans les projets Java. Ce problème sera résolu via OSGI dans le prochain billet car chaque Bundle OSGI a son propre ClassLoader.

Vous pouvez télécharger les projets org.akrogen.gestcv_step1.zip et org.akrogen.gestcv_step1-commons-lang.zip (zip qui contient les projets Java qui utilisent 2 versions de la librairie Apache commans-lang*.jar et qui montre en évidence le problème de ClassLoader) présentés dans ce billet.

» Lire la suite!

Vous pouvez trouver ce billet sur mon nouveau blog avec les informations mises a jour.

Il y a 3 ans j'ai créé le projet GestCV, une application WEB de gestion de CV basé sur Spring, Hibernate, Struts1.x et AJAX. A cette époque je souhaitais utiliser et mettre en évidence toutes les technologies que j'adorais dans un véritable projet.

Aujourd'hui j'ai décidé de me former au développement d'applications Eclipse RCP basé sur les API SWT et JFace que j'ai découvert à travers le développement du plugin Eclipse Akrogen, du projet TK-UI et JFace DOM Databinding. Eclipse RCP me séduit de plus en plus pour les raisons suivantes. Avec Pascal Leclercq nous avons créé ce mois-ci le projet OSGI GestCV qui est une version RCP de GestCV (le projet est en phase d'étude). Plus exactement ce projet est basé sur une architecture client/serveur, autrement dit :

• la couche serveur fournira les services utiles pour la gestion de CV (édition d'un CV, création d'un CV).et sera basée sur OSGI via Spring DM. Les services feront appels à la base de données via Hibernate.
• la couche cliente sera une application Eclipse RCP qui consommera les services hébérgés sur le serveur.

Nous souhaitons utiliser OSGI dans la couche serveur pour démarrer/arrêter à chaud les services sans devoir redémarrer le serveur (très utile en développement comme en production). OSGI fournit d'autres avantages que je tenterais d'expliquer tout au long de ces billets. Je ne sais pas si nous aboutirons ce projet mais mon but premier est de me former aux technologies OSGI, Spring DM, RCP et de les expliquer par des exemples concrets et détaillés dans des billets.

Mon idée est de rédiger des billets qui expliqueront pas à pas comment réaliser une application Eclipse RCP qui communique avec un serveur OSGI avec Spring DM. Concrètement je vais tenter d'expliquer comment développer une petite application RCP qui affiche/met à jour une liste d'utilisateurs récupérée par des services (OSGI) hébérgés sur le serveur. Je tenterais en même temps d'expliquer l'interêt d'OSGI.

Nous avons aussi envisagé d'étudier plus tard (selon notre temps) ce que peut nous fournir le futur projet Eclipse E4 (moteur CSS (qui est à l'origine celui de projet TK-UI ), Modeled Workbench, SWT Flex...) et RAP (qui d'après ce que j'ai compris permet de déployer l'application RCP en mode WEB ).

Si le sujet vous intéresse, vous pouvez commencer par lire le billet [step1] de la série de billets intitulée Conception d'un client Eclipse RCP et serveur OSGI avec Spring DM .

» Lire la suite!

Comme je l'ai annoncé, Spring 3.0 RC1 est officiellement annoncé ... et une page se tourne.

Spring 3.0 apporte de nouvelles choses :

• Support de REST
• Support de Bean Validation (JSR-303)
• Expression Language
• Nouvelle API de Conversion et formattage
• Nouveaux namespaces
• Module OXM
• Configuration par annotations JavaConfig

Mais à coté de cela, il en met d'autres au placard :

• Java 1.4
• Spring 2.5

En effet, Java 1.4 n'est plus supporté car Spring 3.0 utilise pleinement les nouveautés du langage Java 5 : Générique, Var args, Annotations
Même si cela risque de faire râler, c'est compréhensible. Même JDK 1.5 est entré en End of Service Life, ne parlons donc pas de 1.4

Mais concernant Spring 2.5 ? En quoi est-ce lié ?

Vous vous souvenez, il y a un an ? Du gros buzz SpringSource ? Bon je précise, car il y en a eu beaucoup !
Si je dit "Politique de maintenance", est-ce que cela vous parle ? Et oui ;-)

SpringSource will make regular source and binary releases of the current major version of Spring available to the community until the next major version is available (defined as a release candidate for that version).

Autrement dit, avec la sortie de la RC1 de Spring 3.0, il n'y aura plus de mise à jour ( bugfixe, security, .. ) de la branche 2.5 pour la communauté.

Alors, est-ce que la sortie de la RC1 va relancer le Buzz ? :-)