Commentaires sur : Présentation d'OSGI au Paris JUG : naphtaline et peinture fraîche

Par : Cyrille Le Clerc

Cyrille Le Clerc — Thu, 16 Oct 2008 23:42:45 +0000

Merci pour la qualité de votre compte rendu.

Comme vous l’avez rappelé, nous avons essayé de sortir des discours angéliques pour voir l’apport d’OSGI aux différents acteurs du développement « d’informatique de gestion ».

Si nous avons trouvé des avantages différentiants pour les éditeurs de middlewares, en revanche, OSGi nous a semblé manquer de stabilité et de maturité pour convaincre des équipes de développement d’application de gestion qui utilisent aujourd’hui Spring ou les EJB 3.

La RFC 124 – A Component Model for OSGi, en reprenant Spring DM, peut apporter les éléments de productivité qui pénalisent aujourd’hui OSGi face à nos techniques d’injection de dépendances. Encore faut-il que cette RFC soit intégrée à la version finale d’OSGi R4.2 …

Les slides sont disponibles sur le site du Paris JUG à l’url http://parisjug.org/xwiki/bin/view/Meeting/20081014 .

Cyrille Le Clerc (Xebia)

Par : Blog Xebia France - OSGi au Paris JUG - Slides de la présentation

Blog Xebia France - OSGi au Paris JUG - Slides de la présentation — Thu, 16 Oct 2008 19:54:16 +0000

[...] Le Touilleur Express : Présentation d’OSGI au Paris JUG : naphtaline et peinture fraîche [...]

Par : Sébastien Letélié

Sébastien Letélié — Thu, 16 Oct 2008 19:39:37 +0000

Pour faire fonctionner OSGi et l'AOP qui, il est vrai, n'étaient pas prévu pour fonctionner ensemble au départ Martin Lippert a développé un palliatif : Equinox Aspects

Par : Gabriel K.

Gabriel K. — Wed, 15 Oct 2008 22:10:39 +0000

Oui, très bonne présentation, honnête, technique, fouillée. L’impression de faire du neuf avec du vieux était assez forte. Mais pourquoi pas.
J’ai aussi beaucoup apprécié le fait de demander à haute voix : en a-t on vraiment besoin (dans l’informatique de gestion)?

Par : tom

tom — Wed, 15 Oct 2008 11:16:52 +0000

Excellente revue. Beau boulot.

J’ai également fait mon retour sur la soirée.

OSGI : oui mais non
http://www.tomsquest.com/blog/osgi-oui-mais-non/

Tom

Par : Jérôme

Jérôme — Wed, 15 Oct 2008 10:47:04 +0000

Trés bon article pour ceux qui n’y était pas.

Pour en revenir à IOC dans un environnement OSGI, il y a plusieurs solutions qui s’offrent à nous. Spring DM est une des solutions. Le couple Guice – Peaberry en est une autre.

Vous pouvez lire l’article que j’ai écrit sur Javalobby http://java.dzone.com/articles/osgi-and-injection

Par : Maxence

Maxence — Wed, 15 Oct 2008 09:44:21 +0000

Merci pour ce très bon compte-rendu.

J’aimerais également apporter une légère correction vis-à-vis de WebLogic (qui est la même que celle de Luc pour JBoss) : le schéma de class loading par défaut n’est pas le child-delegation-first. Ce modèle est disponible sur configuration uniquement et, depuis les dernières versions, il est déconseillé, au profit du mécanisme de FilteringClassLoader qui gère plus efficacement et proprement ces conflits.

Autre petite précision, qui m’a été donnée par Bill Shannon, le terme « Java EE » doit être préféré à « JEE ».
http://www.java.com/en/about/brand/naming.jsp

Bonne continuation !

Par : Guillaume Carré

Guillaume Carré — Wed, 15 Oct 2008 09:41:02 +0000

C’est la même chose sur WebLogic il me semble, c’est du « parent first ».
Pour pouvoir utiliser les librairies embarquées dans le WEB-INF/lib il faut le spécifier dans le descripteur propriétaire weblogic.xml du WAR (tag prefer-webinf-classes) ou dans le weblogic-application.xml de l’EAR.

Par : Luc Dew

Luc Dew — Wed, 15 Oct 2008 08:05:37 +0000

Merci beaucoup pour le rapport très instructif.
Pour les ClassLoader Jboss l’affirmation « JBoss utilise un class-loader “children first” où une classe de votre WAR sera chargée avant la classe du serveur d’application » n’est pas pas tout à fait exacte.
Sans modifier la configuration par défaut et sans instruction spécifique dans le descripteur de déploiement JBoss utilise un ClassLoader unifié (en fait un unique dépôt de classes auquel sont rattachés les divers ClassLoader). Ceci a comme conséquence que les classes des divers packages ne sont pas isolées et la première chargée l’emporte. C’est bien documenté sur le Wiki JBoss mais un peu déroutant par rapport aux autres serveurs d’application. Par contre, les classes d’un WAR peuvent bien entendu être isolées via une instruction dans le DD ou la conf du serveur, et dans ce cas effectivement on est dans un mode « Children-First » .