Discussion :

[bulbo]

Bonjour la compagnie,

J'ai vraiment du mal avec NetBeans et son utilisation du(des) ClassLoader.

Je vous explique mon soucis:

- J'ai un module A qui définit une classe appelons la "Mere".

- Dans "Mere" il y a une méthode pour charger dynamiquement une classe a partir de son nom stocké dans le fichier de conf passé en argument

- J'ai un module B qui a une dépendance sur A, dans B un classe appelons la "Fille" qui hérite de "Mere".

- "Fille" appelle la méthode de "Mere" en lui passant le nom du fichier de conf a charger

- Le fichier de conf contient le nom d'une classe du module B

Problème a l'exécution j'ai une ClassNotFoundException, la cerise sur le gâteau c'est que dans mes logs (avec log4j) j'ai un log de la classe "Fille" qui me dit ClassNotFound concernant une classe pourtant dans le même jar

Ce que j'en déduis c'est que NetBeans a un ClassLoader différent pour la classe "Mere" et la classe "Fille" et que probablement il n'existe pas de liens entre eux ce qui fait qu'une méthode appelée directement sur une instance de "Fille" ne s'exécutera pas de la même façon suivant qu'elle est définie dans "Fille" ou dans "Mere" avec code identique

N'hésitez pas a me reprendre si je me trompe mais c'est ce que je constate pour le moment ..

Il y a une solution degueu, a savoir passer le ClassLoader de "Fille" en paramètre de super dans le constructeur et d'utiliser ce ClassLoader pour tout charger dans "Mere" ...

Sinon histoire de ne pas mourir idiot, quelqu'un a une idée du pourquoi du comment ils ont fait ce genre de choses ?

Parce que le RCP est vraiment pratique en terme de programmation modulaire mais si un simple héritage fait que "Mere" et "Fille" tourne dans des environnement différents, on va dans le mur c'est sur ..

Bulbo

[n!co]

Salut bulbo,

Tu peux expliquer ce que tu cherches a faire ? de facon conceptuelle sans la problémathique du classloader.

Il se peut que ce soit plutot le design adopté qui pose problème. netbeans offre plusieurs moyens pour dialoguer entre modules, notament avec les Lookups et avec les services du JDK, qui contourne les problèmatiques liées classloader.

n!co

[bulbo]

C'est simple .. en fait non c'est compliqué, c'est pour ça que j'ai crée un module 'helper' pour simplifier le développement d'autres modules.

En fait je travaille sur un système contrôlant du hardware pour faire des mesures.

On a un serveur CORBA qui exécute les mesures et nous avions 2 ou trois GUI à la fois client et serveur CORBA qui communique avec ce serveur de mesure.

L'interaction entre la GUI et ce serveur de mesure nécessite une certaine synchronization qui est obtenue grâce à des appels CORBA.

Cet état de fait implique une logique complexe dans les GUI pour éviter des deadlocks.

Le projet actuel concerne l'unification de ces GUIS dans le NetBeans RCP. Comme je suis pas maso et pour réduire le debug et la maintenance, j'ai écrit un module qui implémente cette communication et toute la partie CORBA.

Dans ce même module j'ai aussi intégré un framework pour faire des Wizard qui vient de l'ancien système, et oui je n'ai pas utilisé celui de NetBeans, juste utilisé la Dialogs API car notre framework est plus puissant que celui de NetBeans.

Ce framework lit les séquences de panels possible pour le wizard ainsi que le mapping 'nom de panel' -> classe java dans un fichier de conf, charge dynamiquement les classes nécessaire et affiche un dialogue nous permettant de configurer de nouvelles mesures.

Il est évident que pour chaque contrôleur de Wizard je ne vais pas recoder le chargement des panels ou la lecture du fichier de conf, donc cette partie est dans le module 'générique'.

Chaque module pouvant effectuer des mesures, a une classe qui hérite du contrôleur de Wizard afin de redéfinir certains comportements suivant les panels (mayFinish, mayCancel ce genre de choses ...)

Seulement comme déjà dit à moins de passer un classloader en argument, ce qui fonctionne soit dit en passant, la classe mère des contrôleur de Wizard ne peut accéder au fichier de conf dans un autre module ou aux classes des panels qui sont dans un autre module aussi.

Et juste une remarque en passant, les Lookups c'est gentil mais je ne vais pas remplacer tout la logique objet de mon projet par des bidouilles a coup de Lookup et d'accès a des singletons.
Programmation modulaire pour moi ne doit pas rimer avec programmation de porc.. Si faire des modules implique de casser les mécanismes de base du langage, non merci.

Bulbo

[n!co]

Il s'agit en effet d'un problème particulier, dont je ne serais t'apporter une grande aide. Je voyais plus une archi API/SPI avec différentes implémentations.

La meilleure réponse que je peux te donner c'est d'aller poser ta question sur la mailing list de plateforme (sur nabble), tu auras à coup sur une réponse précise pour résoudre ton cas de figure.

En ce qui concerne Les Lookups, il s'agit de la base fondamentale du service modulaire de Netbeans, une surcouche au service offert par le JDK en quelques sortes. Et résumé cela à du singleton est plutot réducteur vis a vis de la puissance qu'offre le service de Lookups a tout les niveaux du développement de module.
Ce n'est un rien une programmation "à la porc" et je t'invite fortement à te procurer le livre sur la plateforme Netbeans où tu découvriras beaucoup sur le fonctionnement interne de Netbeans et les meilleures pratiques pour développer des modules.

Bon courage
n!co

n!co

[bulbo]

Il s'agit en effet d'un problème particulier, dont je ne serais t'apporter une grande aide. Je voyais plus une archi API/SPI avec différentes implémentations.

La meilleure réponse que je peux te donner c'est d'aller poser ta question sur la mailing list de plateforme (sur nabble), tu auras à coup sur une réponse précise pour résoudre ton cas de figure.

En ce qui concerne Les Lookups, il s'agit de la base fondamentale du service modulaire de Netbeans, une surcouche au service offert par le JDK en quelques sortes. Et résumé cela à du singleton est plutot réducteur vis a vis de la puissance qu'offre le service de Lookups a tout les niveaux du développement de module.
Ce n'est un rien une programmation "à la porc" et je t'invite fortement à te procurer le livre sur la plateforme Netbeans où tu découvriras beaucoup sur le fonctionnement interne de Netbeans et les meilleures pratiques pour développer des modules.

Je suis d'accord que les Lookups c'est puissant, et je fais des trucs bien puissant avec aussi (j'ai aussi lu le bouquin, pas tout les chapitres mais j'ai déjà appris plein de trucs, il est vraiment top)

Dans le cas précis qui m'intéresse, les lookups ne sont en rien une solution propre et c'est pourquoi j'ai fait cette remarque ..
Si je dis pas de bêtises, si j'utilise un lookup pour récupérer la classe mère
je n'aurai plus le problème du classloader mais par contre plus d'héritage possible

De manière générale je trouve qu'il y a juste de petits abus de singletons dans NetBeans et personnellement niveau design j'essaye vraiment de réduire ce genre d'approche, mais après c'est un choix personnel.

Eventuellement j'essaierai Nabble et je posterai la réponse ici, si j'en ai une plus propre que de passer le classloader en argument ou d'utiliser le classloader qui peut accéder a toutes les classes de la plateforme..

Bulbo

[bulbo]

Bon après une longue recherche sur Nabble je me suis rabattu sur la solution suivante (comme je m'en doutais la solution quasi systématique aux problèmes de loading : Lookups):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Thread.currentThread().getContextClassloader()

Ça évite le passage en argument et ça limite au module courant .. donc exactement ce que je veux.
Ca reste un poil de la bidouille et oblige une programmation différente qu'en dehors de la plateforme alors que le code en question n'a rien avoir avec mais ça marche alors je vais faire avec..

Bulbo