La présentation d'OSGi était plus qu'aléchante : plus de problèmes de classloaders (voir commons-logging ou xerces sous WebSphere 5...), possibilité de mise à jour a chaud, de reconfiguration, séparation explicite de la partie "publique" d'un module et de son implémentation...
La plateforme OSGi est disponible depuis longtemps puisqu'Eclipse est basé dessus, aussi ça fait un peu mal au coeur de penser qu'on galère avec les déploiements JEE. L'équipe de Spring a fait un travail impressionnant pour mettre en place un modèle "POJO" sur OSGi :
- Codage totalement indépendant de l'API OSGi -> test unitaires simples
- Support complet pour les tests d'intégration (déploiement d'un vrai conteneur OSGi)
- Toute une série de à utiliser dans le contexte Spring pour accéder aux autres modules, comme à n'importe quel autre bean, sans aucun changement dans le code.
Ca donne vraiment envie... il y a cet AM une présentation "pratique" sur l'écriture d'une appli OSGi s'exécutant sur un serveur d'application.
0 commentaires:
Enregistrer un commentaire