Discussion :

[Deaf]

Bonjour,

J'ai un gros problème d'utilisation de la réflexivité dans un contexte comprenant plusieurs classloaders.

Pour être précis:
- j'ai un module A dans un classloader A qui permet de lire du XML et de le traduire en objet Java,
- j'ai un module B dans un classloader B qui appelle le module A pour lire des fichiers XML.

Le problème vient du fait que le module A utilise la réflexivité pour savoir comment désérialiser le XML. Le mapping se fait via des annotations sur les champs de la classes Java.
(Ceux qui connaissent ont dû se douter que je parle de SimpleXML...)

Deux obstacles me bloquent pour l'instant:
- Les annotations que trouve le module A ne sont pas celles qu'il attend puisqu'elles ont été chargées par un classloader différent (qui n'est pas un parent). Résultat : il considère que la classe n'a pas d'annotations et n'arrive pas à affecter les champs,
- L'objet à déserialiser contient des Enum (sans plus de précision). La class Enum comprenant les valeurs à déserialiser se trouve dans le module B et n'existe pas dans le module A. Donc il n'arrive pas non plus à m'initialiser le champ (dans le cas où j'arrive à contourner salement le premier point).

Avez-vous une idée dont on gère la réflexivité quand on a plusieurs classloaders (genre, dans OSGi...)?

D'avance, merci

[tchize_]

Ni l'un ni l'autre n'est parent de l'autre. Parce que si c'est le cas, l'architecture et curieuse et je me demande comment B arrive à appeler le parseur dans A....

[DarkMolo]

Bonjour,

J'ai eu une fois besoin d'utiliser différents classloader, chacun pour un module, j'obtenais les mêmes problèmes que tu viens de citer, tournant en rond, ce que j'avais fait viole peut-être le principe initiale de l'application, comme quoi elle doit rester modulaire, qu'un module doit fonctionner sans les autres...

J'avais créé un ClassLoader global au démarrage de l'application, un ClassLoader qui serait rendu accessible au reste de l'application, comme ceci:

Code :

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

1
2
3
4
5
6
7
 
URL[] urlModules = new URL[modules.length];
int iCnt = 0;
for (File fileIt : modules) {
	urlModules[iCnt++] = fileIt.toURL();
}
ClassLoader globalClassLoader = new URLClassLoader(urlModules, parentClassLoader);

En espérant que nous parlons bien de la même chose .

[Deaf]

Ni l'un ni l'autre n'est parent de l'autre. Parce que si c'est le cas, l'architecture et curieuse et je me demande comment B arrive à appeler le parseur dans A....

Il s'agit d'OSGi, chaque module (bundle) est chargé dans un classloader différent.
Ensuite, des liens (Wire) sont établis entre les classloader pour satisfaire les dépendances (qui sont déclarées dans le Manifest).

En fouillant dans les classloaders, je me suis rendu compte que la librairie que j'utilise semble se baser sur le ContextClassLoader. Or j'ai cru comprendre qu'aucune garantie n'est faite sur ce dernier dans un contexte OSGi.

Du coup, la classe Toto du classloader B et celle que le module A trouve depuis le contextClassLoader ne sont pas les mêmes (bien qu'elles proviennent de la même source).

A priori, une solution peut donc être de positionner le contextClassLoader avant chaque appel puis rétablir l'ancien, mais cela ne me plaît guère car je ne peux pas le généraliser à cause des Enum.

[tchize_]

je ne sais pas comment OSGI marche ni fait le "wire" entre les dépendances, désolé. mais c'est justement ce que je suggérerais, passer le classloader à utiliser en question.