Discussion :

[Mr. Magne]

Bonjour,
Je suis un nouveau venu dans le monde de spring et je me pose quelques questions...
Notre application est standalone, basée sur eclipse RCP et structurée en plugins avec des points d'extensions.
Pour l'instant pour utiliser spring nous avons créer une dépendance vers le plugin org.springframework.bundle.spring. Ce qui nous permet d'utiliser spring dans notre application (après quelques soucis de configuration de classpath il est vrai...)

A mon avis, spring fera un peu double emploi sur certains aspects avec le mécanismes de points d'extensions des plugins eclipse RCP. Quelqu'un a-t-il un bon exemple de cohabitation entre les deux ?

J'ai vu qu'il existe un plugin spring-DM (anicennement spring OSGI si j'ai bien compris). Que nous offrira exactement ce plug-in par rapport à la simple utilisation de org.springframework.bundle.spring ? J'ai vu pas mal de choses sur ce plug-in liées à des serveurs d'application (je ne suis pas super au point sur les serveurs d'application mais je pense que ça n'a rien à voir avec notre petite application standalone, non ?), est-ce obligatoire ? ce plug-in offre-t-il un interêt sans serveur d'application ?

Merci de votre aide

[djo.mos]

Bonjour,
Je ne suis pas sûr de bien te suivre sur la terminologie.
Sinon, t'as Spring DM (Dynamic Modules) qui te permet de Spring'ifier un bundle OSGi via un extender : en gros, le contenur OSGi démarre l'Extender de Spring DM, et celui-ci itère sur les autres bundles pour voir s'ils sont Spring-enabled (via une entrée dans leur manifest).
Si c'est le cas, alors il lance ces bundles mais surtout crée à leur place leur applicationContext (définie par des fichiers XML Spring dans META-INF/spring).

Ca s'intègre entre autres dans Eclipse (et eclipse RCP).

Par contre, ça n'a aucun lien avec le mécanisme d'extension d'Eclipse.
Tu confnds peut être avec les services OSGi ? En effet, Spring DM te permet en une ou deux lignes XML d'exposer un Bean Spring en tant que Service OSGi, et de même pour importer un service OSGi en tant que Bean Spring.
Ce qui est infiniment plus commode que l'export/import de services via l'API d'OSGi (très pénible et impossible AMHA à réaliser correctement et dans les règles d'art par un un représentant réel de la race humaine de nos temps ).

Le seul point qui peut bloquer est la DI avec les composants d'Eclipse (Views et Editors) car ils sont pas crées par Spring mais par Eclipse.

Tu peux résoudre ça soit:
- A la main en fournissant dans le point d'extension le nom d'une factory qui va piocher les vues/editeurs dans l'applicationContext
- Utiliser cet excellent utilitaire développé par MArtin Lippart qui fait ça à ta place : http://martinlippert.blogspot.com/20...xtensions.html

Voilou.

[Mr. Magne]

Merci bien de ta réponse.

Si je te suis bien, pour l'instant en utilisant le plug-in org.springframework.bundle.spring je n'aurai spring que de disponible que dans mon plug-in qui en dépend, alors qu'avec le Spring DM Spring sera activé dans tous les plug-in qui ont le petit mot magique dans leur manifest, et créera tous les applications context, c'est ça ?

Quand je parlais du double emploi entre spring et le point d'extension, je voulais dire en définissant ses propres points d'extension: par exemple j'écris un plug-in A qui défini une interface IMonInterface et un point d'extension permettant de définir une implémentation de cette interface. Mon plugin B pourra donc implémenter cette interface et fournir cette implémentation à mon plug-in A en utilisant ce point d'extension. C'est de cette manière que je procédait avant d'utiliser Spring et pour moi les deux se marchent un peu sur les pieds à ce niveau...

Je pense que je dois pouvoir résoudre ce "conflit" en utilisant la méthode de la factory ou le point d'extension de Martin Lippart, je vais me pencher là-dessus. Si tu as un petit exemple de ce genre de factory je suis preneur, car j'étais déjà tombé sur cette piste mais exposée vraiment trop succintement
EDIT: en fait le code de Martin Lippart me semble être un très bon exemple

Merci de ton aide