Discussion :

[dahtah]

Bonjour à tous,
J'ai fait un petit système de plugin très simple, et je me pose quelques questions :

• Est-ce que je dois utiliser un ClassLoader par plugin ? Je pense que oui séparation des ressources)
• Mes plugins doivent pouvoir instancier les classes de mon projet, leur ClassLoader doit donc hériter de celui du projet? (Je pense que oui également)
• Question sécurité, auriez-vous des pistes pour faire du sandboxing rudimentaire (éviter qu'un plugin ai accès au appels systèmes (à "rm -rf /" par exemple)). (Pas trop d'idée)

Voilà, j'aimerai avoir vos avis éclairés sur la question.
Merci,

[adiGuba]

Salut,

• En effet des classloader séparé permettaient de libérer les ressources d'un plugins sans impacter les autres. Donc je dirais oui...
• Théoriquement oui.
• Là c'est plus dur. Je dirais que ce doit être possible via le SecurityManager, mais je n'ai jamais toucher à cela...

a++

[dahtah]

Salut,

• Là c'est plus dur. Je dirais que ce doit être possible via le SecurityManager, mais je n'ai jamais toucher à cela...

J'ai regardé ça rapidement ce we, et j'ai pas trouvé beaucoup d'articles (ou très vagues). Si quelqu'un à des liens, il serait les bienvenus... Cette partie à l'air hardu...

Question annexe : comment gérez-vous vos systèmes de plugins (OSGI, JPF...). J'ai regardé ces solutions, mais elle me semble si lourde pour le besoin que j'en ai.
Si ça vous intéresse, les sources du gestionnaire de plugin du serveur Openfire (XMPP) sont très intéressante.
Merci...

[Invité]

J'ai regardé ça rapidement ce we, et j'ai pas trouvé beaucoup d'articles (ou très vagues). Si quelqu'un à des liens, il serait les bienvenus... Cette partie à l'air hardu...

Question annexe : comment gérez-vous vos systèmes de plugins (OSGI, JPF...). J'ai regardé ces solutions, mais elle me semble si lourde pour le besoin que j'en ai.
Si ça vous intéresse, les sources du gestionnaire de plugin du serveur Openfire (XMPP) sont très intéressante.
Merci...

Salut,

J'utilise personnellement OSGi, et plus particulièrement Felix (implémentation de Apache).
Je ne trouve pas ça trop lourd en soit, il faut juste appréhender les concepts et pour la puissance que ça apporte je trouve l'investissment en temps intéressant.
à noter que OSGi spécifie aussi la sécurité et permet une gestion plus flexible encore de JAAS, afin de changer dynamiquement les permissions (pour un module, pour un signataire, ...). Le tuto felix (http://felix.apache.org/site/apache-...-tutorial.html) est, je trouve, assez bien foutu...
Un autre lien pouvant être intéressant : http://felix.apache.org/site/apache-...embedding.html comment embarquer felix dans ton application !

A noter que felix n'implémente pas encore tous les aspects de la sécurité, mais equinox le fait. De plus avec la nouvelle spécification, il y aura un moyen standard de démarrer un noyau OSGi, ce qui rendra ton application totalement indépendate de l'implémentation (normalement )

[Baptiste Wicht]

Personnellement, j'ai recodé mon propre système de plugin : http://baptiste-wicht.developpez.com...tting-started/

Personnellement, j'ai commencé à implémenter avec des classloader séparé qui héritaient d'un parent commun définie par le coeur de l'application modulaire, mais j'ai eu beaucoup de problèmes par la suite avec des librairies comme Spring/Hibernate et d'autres encore. Pour finir, je passe par le class loader système, mais c'est beaucoup moins propre.

Je n'avais pas implémenté de système de securité, donc effectivement, les plugins peuvent tout faire.

Si j'ai tout recodé à la main plutôt que d'utiliser quelque chose d'existant, c'était surtout pour améliorer mes connaissances Java, mais je suis en train de lorgner du côté d'Osgi actuellement.

[dahtah]

Le tuto felix (http://felix.apache.org/site/apache-...-tutorial.html) est, je trouve, assez bien foutu...

j'ai parcouru en diagonale. Ca m'a l'air complet et intéressant.

Un autre lien pouvant être intéressant : http://felix.apache.org/site/apache-...embedding.html comment embarquer felix dans ton application !

Effectivement, ça c'est top.

A noter que felix n'implémente pas encore tous les aspects de la sécurité, mais equinox le fait.

Peux-tu préciser un peu? je saisi pas le lien entre felix et equinox... (à moins qu'il y en ai pas et que tu parles d'une alternative?)

De plus avec la nouvelle spécification, il y aura un moyen standard de démarrer un noyau OSGi, ce qui rendra ton application totalement indépendate de l'implémentation (normalement )

Peux-tu préciser également?

Personnellement, j'ai commencé à implémenter avec des classloader séparé qui héritaient d'un parent commun définie par le coeur de l'application modulaire, mais j'ai eu beaucoup de problèmes par la suite avec des librairies comme Spring/Hibernate et d'autres encore. Pour finir, je passe par le class loader système, mais c'est beaucoup moins propre.

Je fais plus ou moins la même chose, dezip du jar, chargement des éléments dézippés dans un classloader héritant du classe loader système. De toute façon, je suis obligé d'hériter du classe loader système, pour que mes plugins aient accès aux fonctions de mon système.
Maintenant, ça me gène de laisser tous les droits aux plugins. Mais vu qu'un sandbox ça à l'air (très) compliqué à implémenter et que ce n'est pas le coeur de mon appli, mieux vaut peut-être se tourner vers un framework.
Merci à tous en tout cas de vos intervention...

[Baptiste Wicht]

Je fais plus ou moins la même chose, dezip du jar, chargement des éléments dézippés dans un classloader héritant du classe loader système. De toute façon, je suis obligé d'hériter du classe loader système, pour que mes plugins aient accès aux fonctions de mon système.
Maintenant, ça me gène de laisser tous les droits aux plugins. Mais vu qu'un sandbox ça à l'air (très) compliqué à implémenter et que ce n'est pas le coeur de mon appli, mieux vaut peut-être se tourner vers un framework.
Merci à tous en tout cas de vos intervention...

Personnellement, je ne dézippais pas le Jar, je l'ajoutais directement dans le classloader. C'est pas plus simple ?

[dahtah]

Personnellement, je ne dézippais pas le Jar, je l'ajoutais directement dans le classloader. C'est pas plus simple ?

Si, c'est sans doute plus simple, mais mon idée était de garder la main sur le chargement du jar (ne pas charger le manifest, ne pas charger le jar si aucune classe n'implémentait l'interface plugin...)
En fait, je charge seulement ce que je veux (typiquement, les .class) dans le classLoader, tout en laissant accès aux ressources du plugin par chemin relatif du dossier dézippé (que je retransmet au plugin si besoin).
Après est-ce que c'est la meilleure méthode...

[Invité]

j'ai parcouru en diagonale. Ca m'a l'air complet et intéressant.

Effectivement, ça c'est top.

Peux-tu préciser un peu? je saisi pas le lien entre felix et equinox... (à moins qu'il y en ai pas et que tu parles d'une alternative?)

Peux-tu préciser également?

Je fais plus ou moins la même chose, dezip du jar, chargement des éléments dézippés dans un classloader héritant du classe loader système. De toute façon, je suis obligé d'hériter du classe loader système, pour que mes plugins aient accès aux fonctions de mon système.
Maintenant, ça me gène de laisser tous les droits aux plugins. Mais vu qu'un sandbox ça à l'air (très) compliqué à implémenter et que ce n'est pas le coeur de mon appli, mieux vaut peut-être se tourner vers un framework.
Merci à tous en tout cas de vos intervention...

Alors :

• j'ai été trop vite surement : felix est une implémentation d'OSGi par le fondation Apache, equinox est celle d'eclipse (eclipse est en gros un noyau OSGi avec tout plein de plugin autour). Il existe aussi knopflerfish parmi les implémentations libres connues.
• La spécification 4.2 décrit en plus du reste une API pour lancer le framework avec des classes standards. Jusqu'ici chaque implémentation implémente son système de démarrage, mais ceci vient d'être uniformisé.

L'avantage de OSGi (je trouve) est sa spécification, très bien écrite, très complète (heureusement pour une spec ), la communauté qui existe avec, des implémentations libres de qualité, et un algorithme de classloader déterministe en cas de présence multiple d'une même classe !!!!!!
Il gère différentes versions de chaque plugins, et vraiment permet de faire énormément de choses, mais je vais pas faire un tuto ici sur le forum

Voilà j'espère avoir bien complété maintenant

[dingoth]

J'entends souvent qu'OSGi est le char d'assaut utilisé même pour tuer une mouche. Tu dis que tu ne trouves pas ça trop lourd, pourquoi ?

[Invité]

Ben quand je l'utilise (felix par exemple), j'ai un jar de quelques kilo (360K je crois), qui se démarre très facilement. Ensuite je peux faire mes plugins avec la seule condition que je doive déclarer une classe d'activation dans le manifest est des imports. Ensuite tu peux programmer tranquillement tout en jouissant de toute la puissance de OSGi.
Je suis assez pour utiliser ce qui existe déjá et est bien si ça n'apporte pas d'énormes coups et là je trouve personnellement que ça a été. On peut rentrer petit à petit dedans, sans maîtriser tout dès le début.
Réécrire un système de plugin perso qui fait moins de choses, tomber dans les pièges et problèmes de classloader etc, etc... je ne sais pas si c'est vraiment rentable par rapport à prendre OSGi.
Après il existe peut-être d'autres systèmes que je ne connais pas et qui font moins de choses mais très bien et peuvent suffire... Mais je trouve que felix pour un système simple et pas si lourd que ça