Version imprimable
La nouvelle version de Spring est officiellement sortie en version 2.5.
Vous pouvez déposez ici vos témoignages, retours d'expériences, regrets, manques a propos de cette nouvelle version.
Annonce officielle de la sortie
Changelog de la version
Téléchagez la nouvelle version
Du très très bon, surtout par l'enrichissement du vocabulaire des annotations qui simplifient grandement la configuration. Spring est à mes yeux réellement incontournable dans l'édification d'application de taille conséquente.
Uniquement sur l'aspect des annotations, j'ai peut-être une réaction bête mais cela semble pour moi être un mécanisme plutôt intrusif. Ca n'est pas spécifique à Spring. D'autres frameworks comme Hibernate utilisent les annotations sur les POJOs pour y paramètrer la persistance.
Evidemment, par rapport au gros avantage que cela peut fournir en matière d'injection de dépendances, cela parait être un moindre côut. Mais tout de même ...
Je vient de mettre à jour mon application Spring 2 vers 2.5 et: CA MARCHE.
Donc, premier retour d'expérience, pas de problème de compatibilité (ce qui n'est pas si évident que cela, surtout vue le nombre de 3rd party librairies de Spring).
Un seul regret, le JAR qui se prénommait avant spring-mock s'appelle maintenant spring-test, il va donc falloir changer les classpath des 30-40 applications sur lesquels l'équipe travail. C'est vraiment dommage!
Quels sont les avantages que je voit?
- distribution en module: bien que je ne l'ai pas utilisé cela permet de réduire la taille d'une application si elle n'utilise qu'une mince partie de Spring
- full aspectj support
Ma plus grande interrogation est au niveau du support des annotations qui effectivement va à mon sens à l'inverse de l'idée de base de Spring: un framework non intrusif. De plus, les fichiers de configuration de Spring été en quelque sorte un super diagramme de classe qui permettais de voire directement toutes les relations entre les objets (et certain logiciel le faisait de manière graphique). Donc je ne pense pas les utiliser.
J'avais eu l'occasion de lire des retours de migration, positif eux aussi, mais cela fait toujours plaisirs de voir que cela se passe généralement bien.
C'est clair que le renommage peut être ennuyant. Pareil pour ceux qui utilise le jar complet, et qui utilise Spring MVC, il devront tout de même ajouter le jar spring-web en plus. Mais c'est une des rares modifications à réalisées.
En ce qui concerne les annotations, je te rejoins sur certains points.
Le fait d'avoir un fichier XML à part permet d'etre complètement indépendant de Spring. Mais lors de la présentation Spring 2.5 à Javapolis, SpringSource à confirmer que l'XML était toujours d'actualité, avec l'apparition des nouveaux namespace. Les annotations sont une alternative, pas un remplacement.
Cela dit, cela permet de réduire assez bien la configuration Spring.
Sinon pour information, la distribution en module était déjà présente dans spring 2.0 ;-)
Par contre, lors de la présentation, j'ai eu l'occasion de voir une chose intéressante :
Et le service en question est configuré via Spring, de manière totalement transparente. Merci Spring, AspectJ et Load-time-weaving ..Code:
2
De plus, j'ai appris l'existence d'un serveur Http embarqué dans Java 6 !
Et celui-ci pourra être utilisé par Spring 2.5.1 pour déployer des services HttpInvoker, sans nécessite un tomcat ou autre.
Bref, pas mal de fonctionnalités sympathiques !
Autant pour moi pour la distribution en module déjà présente :oops:, mais maintenant elle est plus recommandée et spécialement car les JAR sont OSGi compliant, bien que je n'ai toujours pas réellement compris ce que c'étais et l'intérêt ...
Sinon, pour la possibilité de faire, comme tu le disait, un new sur un objet et que Spring le configure, donc l'auto détection et configuration au loadtime des classes, comme pour le support des annotation, ça perverti le principe d'injection de dépendance car tu es occupé ici à donner une dépendance en faisant un new (comme en mettant une annotation). Et surtout tu n'applique plus le pattern de programmation par patron. Par contre ça peut être très pratique pour de la migration, mais j'imagine qu'il faut configurer la JVM pour pouvoir utiliser ça (il faut lancer l'agent AOP qui s'occupera de la configuration au loadtime) ce qui n'est pas toujours possible dans certain environnement professionnel assez fermer.
Clair que c'est pas forcement possible partout. Normalement, si j'ai bien compris, il suffit d'utiliser un JavaAgent. C'est un paramètre à passer à la JVM effectivement.
Cela dit techniquement, je trouve ca fun :)
Même si je ne sais pas si cela sera fort utilisé.
Et, hélas, l'utilisation d'un JavaAgent est réservé à JAVA5.
Pauvre de moi qui utilise encore Java 1.4, je n'ai pas la possibilité d'utiliser toutes ces nouveautés passionnantes :cry:
La spécification OSGi te permet de partager des classes entre plusieurs applications au sein de la même JVM, d'arrêter ou de démarrer chaque composant séparément, de charger différentes versions d'un même jar et de gérer au mieux les dépendances et la sécurité.Citation:
Envoyé par woodwai
C'est beaucoup utilisé dans les serveurs d'application J2EE. A terme, on peut imaginer aussi que lorsque tu lances par exemple 2 instances d'Eclipse (ou juste plusieurs programmes Java) sur ton PC, toutes les classes ne soient pas chargées en double.
Petite précision au sujet de la version 2.5, elle comprend un bug qui empêche le lancement de WebSphere 5.1 ne mode debug (peut-être certain autres serveurs d'application aussi).
Ce bug a déjà été corrigé et une nouvelle version est déjà disponible en téléchargement.
De même pour l'envoi de mail, il y a des bugs notamment sur SendMailException qui ont été corrigés dans la 2.5.1.Citation:
Envoyé par woodwai