PLUG-IN ET CHARGEMENT DYNAMIQUE DE MODULES, INTROSPECTION
Twinuts
Messages postés
5375
Date d'inscription
dimanche 4 mai 2003
Statut
Modérateur
Dernière intervention
14 juin 2023
-
20 févr. 2008 à 13:59
Twinuts Messages postés 5375 Date d'inscription dimanche 4 mai 2003 Statut Modérateur Dernière intervention 14 juin 2023 - 21 févr. 2008 à 09:57
Twinuts Messages postés 5375 Date d'inscription dimanche 4 mai 2003 Statut Modérateur Dernière intervention 14 juin 2023 - 21 févr. 2008 à 09:57
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/45796-plug-in-et-chargement-dynamique-de-modules-introspection
https://codes-sources.commentcamarche.net/source/45796-plug-in-et-chargement-dynamique-de-modules-introspection
21 févr. 2008 à 09:57
afin de mieux me faire comprendre, regarde sur cette source (1) et interrese toi à la classe JarLoader (2)
(1) -> http://www.javafr.com/codes/MOTEUR-PLUGIN_44098.aspx
(2) -> http://files.codes-sources.com/fichier.aspx?id=44098&f=Moteur+de+plugin\Admin+PlugIn+version\src\com\daedric\lang\jar\JarLoader.java
21 févr. 2008 à 08:48
Je pensais que java faisait comme C++ pour les attributs de classes, qu'il les rendait automatiquement private.
Pour le second point, je ne vois pas en quoi mon loader est dépendant de ma couche métier. Peut-être parles-tu de la classe PlugInStorage. Mais cette classe ne stocke aucune info spécifique à mes plugins, elle permet juste de faciliter le stockage, le tri et la recherche d'élément (cf PlugInStorage.java, dans le zip).
Je pense intégrer le chargement de classe à partir d'un .jar, mais pour mon projet (qui nécessitera des ajouts réguliers de plug-in) il est plus aisé de charger des .class indépendant. Je ne sais pas si je me suis fais comprendre, mais en gros, si on prend l'exemple du PlugedPlane, il faudra que j'ajoute régulièrement de nouveaux avions.
Merci pour tes remarques.
20 févr. 2008 à 18:22
"Tu pourrais préciser le coup de la restriction de portée?"
> Je parle du qualifieur 'private' sur tes variables globales afin d'éviter les trous de secu
Pour le cas du chargement de plugin bah c'est assez simple:
Tu sépares le chargement du byte code de ta couche métier (chargement du plugin) en mettant au point une sorte de jarloader (chargement des classes d'un jar en fonction d'un entry point du fichier manifest) rien de plus. En gros cette classe permet simplement de charger le byte code des classes java se trouvant dans un jar et de pouvoir créer des instances d'objet, des invoke sur les méthodes de celui-ci, etc...
Ensuite tu peux y ajouter ta couche métier en incluant ton template de plugin... et ainsi éviter une dépendance entre le loader et la couche métier, afin de rendre le loader le plus générique possible.
20 févr. 2008 à 17:51
Pour les règles de nommage, je m'excuse mais je commence juste le java et je viens du monde C++.
Tu pourrais préciser le coup de la restriction de portée?
De même pour le type générique?
Il me semble que je n'impose pas de type particulier. Il faut juste que les classes plug-in hérite d'une mère définie en interne dans le programme afin de pouvoir accéder aux méthodes.
J'aurais pu mettre en place un chargement dynamique des méthodes, mais cela ne me sert à rien dans mon projet.
20 févr. 2008 à 13:59
ne voyant rien d'assez pechu, je repasse le code en débutant
ptites remarques :
1 - Tu aurais quand même pu repsecter un minimum les règles de nommage de sun et ne pas mettre des majuscules à toutes tes méthodes et noms de variables....
2 - Tu aurais pu mettre une restriction sur la portée de tes variables globales...
3 - Tu aurais pu faire en sorte que ton code charge un plugin de type générique, sans imposer une classe précise afin de déléguer la couche métier à un moteur de plugin...