Glassfish est un des premiers serveurs d'applications à avoir adopté OSGi en l'exposant aux développeurs d'applications. Le document 'OSGi Application Development using GlassFish Server' (PDF) décrit en détail comment exploiter les fonctionnalités de la spécification 'Enterprise OSGi' dans le cadre de Glassfish.

Ce tutorial très détaillé propose de découvrir JavaEE 6 en utilisant Eclipse et Glassfish.

Le support de la présentation 'OSGi & Java EE in GlassFish' est disponible . Il donne un bon aperçu de la façon dont Glassfish permet aux développeurs d'exploiter le meilleur des deux mondes (JavaEE et OSGi).

L'actualité d'OSGi en entreprise est dense en cette fin d'année : après l'annonce de la création du projet Gemini par Oracle et Spring Source, c'est IBM qui propose son implémentation de la spécification 'OSGi Entreprise'.
Cette implémentation, nommée 'OSGi Applications Open Alpha', permet d'ajouter à un serveur WebSphere 7 les fonctionnalités de déploiement et d'exécution de modules OSGi.

Avec le soutien d'Oracle, d'IBM, des communautés Spring, Glassfish et JOnAS, il ne fait maintenant plus de doute que l'utilisation d'OSGi côté serveur va se généraliser.

Ludovic Champenois annonce sur son blog la version 1.0 du 'GlassFish Tools Bundle For Eclipse'. Cette approche nous semble intéressante : les équipes de développement sont rarement amenées à changer de serveur d'applications, leur proposer un outillage packagé et pré-configuré est plus simple que de partir de la distribution trop générique qu'est Eclipse IDE for Java EE developers. Félicitations à l'équipe de Sun et souhaitons que Glassfish trouve sa place chez Oracle.

La version 3 de Glassfish est basée sur OSGi. L'article 'GlassFish V3 Extensions, part 2 : Managed OSGi bundles', explique comment déployer un bundle OSGi dans Glassifh V3.

Sun annonce la disponibilité d'une version d'Eclipse 'packagée' pour les développeurs ciblant Glassfish: GlassFish Tools Bundle for Eclipse. La distribution contient Eclipse WTP 3.4.1, Glassfish V2 et V3 Prelude, les plugins Eclipse d'intégration de ces deux serveurs et optionnellement un JDK 1.6.

Le blog de l'un des contributeurs explique la raison de cette offre. Certains y verront un manque de cohérence par rapport à NetBeans, pour notre part il nous semble parfaitement logique et pragmatique que Sun propose cette distribution, sachant que des offres équivalentes existent côté JBoss ou Spring. Maintenant une annonce comme celle-ci, quelques jours après l'annonce d'un possible rachat d'IBM par Sun, va certainement succiter de nombreux commentaires...

La modularisation des librairies est un des principaux objectifs pour Java 7. Malgré sa rapide adoption et sa standardisation dans le cadre du JCP (JSR 291), OSGi ne semble pas convenir aux équipes de Sun (exception fait de celle travaillant sur Glassfish V3). Le premier choix de Sun aura été de pousser une JSR concurrente (JSR 277). Dirigée de façon très maladroite cette spécification n'aboutira pas, Sun ayant finalement décidé de ne pas la retenir pour Java 7. Ce choix attendu depuis longtemps aurait logiquement dû se faire au bénéfice d'OSGi, malheureusement Sun a pour l'instant choisi une autre direction en lançant un projet nommé Jigsaw. Ce dernier sera développé pour les besoins internes de Java 7 et ne sera pas spécifié dans le cadre du JCP.

L'annonce de l'abandon de la JSR 277 a dans un premier temps été bien accueillie par la communauté OSGi, d'autant plus que Sun déclare vouloir travailler avec les experts OSGi. Mais la satisfaction a rapidement fait place à de l'inquiètude ('Hope, Fear, and Project Jigsaw'), voire à de la colère ('Spice is Not a Recreational Drug'). Ces réactions me semble légitimes face au choix de Sun de contourner le JCP et d'écarter de nouveau OSGi sans avancer d'argument technique. Quoiqu'il en soit on comprend mal comment Jigsaw pourra être finalisé pour la sortie de Java 7 alors que le projet par de zéro... Certains en sont conscients puisque Java 7 ne sortira pas avant début 2010.

L'annonce de Glassfish V3 Prelude a été largement relayée et Sun a beaucoup communiqué sur l'adoption d'OSGi comme socle de cette version. L'implémentation d'OSGi intégrée est Felix d'Apache, mais les développeurs de Glassfish se sont fixés comment objectif de pouvoir faire fonctionner le serveur avec d'autres implémentations d'OSGi. Le blog de Ludovic Champenois montre comment lancer Glassfish en utilisant Equinox : 'GlassFish v3 Prelude OSGi support: Is it really true?'.

L'article 'GlassFish on Eclipse Ganymede' décrit comment utiliser Glassfish comme serveur de test avec WTP 3.0.

Cet autre article, 'Improving Glassfish Deployment Performance in Eclipse' explique comment améliorer les performances de publication de WTP vers un serveur Glassfish.

Un petit tutorial expliquant comment faire fonctionner Glassfish V3 dans Eclipse.

Pour en savoir plus :
'GlassFish v3 TP2 on Eclipse'

SpringSource, la société derrière Spring, crée l'évènement en annonçant son propre serveur d'applications : SpringSource Application Platform (version beta). Le point intéressant pour la fondation Eclipse est que le socle de ce serveur d'applications est Equinox, l'implémentation OSGi de la fondation Eclipse. Pour simplifier, SpringSource Application Platform est un packaging d'Equinox + Tomcat + Spring.

Certains vont certainement y voir un pied de nez à Java EE, alors qu'en fait il s'agit plus d'une anticipation sur Java EE 6 et sa notion de 'Profile', pour preuve le fait que Rod Johnson, le créateur de Spring, annonce comme hautement probable le fait que SpringSource Application Platform soit certifié JavaEE 6.

Quoiqu'il en soit, il est clair qu'OSGi fait l'unanimité : rappelons que la plupart des serveurs JavaEE l'intègre ou sont en passe de le faire (WebSphere, JOnAS, GlassFish, JBoss...),

Pour en savoir plus :
SpringSource Launches New Application Server without Java EE
Introducing the SpringSource Application Platform
JOnAS 5 et OSGi

L'équipe de développement du serveur Glassfish annonce que la version 3 sera basée sur OSGi. Un premier prototype basé sur Félix (implémentation OSGi d'Apache) a été réalisé. Le choix définitif de l'implémentation OSGi qui sera intégrée à GlassFish V3 reste à faire, Equinox fait partie des implémentation étudiées.

Cette annonce préfigure peut-être un changement de position de Sun sur le débat JSR291 (OSGi) contre JSR277 (Java Module System) ?

Pour en savoir plus :
'GlassFish V3 runs on OSGi'
Une discussion sur le potentiel d'OSGi

Le projet EclipseLink, créé suite à la mise en open-source de TopLink par Oracle, a été choisi pour être l'implémentation de référence de la spécification JPA 2.0 (JSR 317). Dans la pratique cela signifie notamment son intégration dans Glassfish V3.

Pour en savoir plus :
'Eclipse Announces EclipseLink Project to Deliver JPA 2.0 Reference Implementation'
La page de la JSR 317 (JPA 2.0)

Cette page explique comment configurer Eclipse WTP 2.0 (basé sur Eclipse 3.3) pour utiliser un serveur Glassfish.

Pour en savoir plus :
La page: 'Eclipse 3.3 and GlassFish Java EE 5 integration'

Sun propose un plugin Eclipse pour Glassfish (son implémentation de Java EE 5). Ce plugin est compatible avec Eclipse 3.1 et WTP 1.0.

Pour en savoir plus :
Télécharger le plugin pour Glassfish