Salut,
Dans le cadre d'un projet, j'ai plusieurs contextes liés à des versions différentes d'un serveur. J'ai une version de bibliothèque de connexion différente par version de serveur (Il s'agit d'un JAR propriétaire + des JARs Apache (commons, httpclient...). Afin de permettre à plusieurs contextes de cohabiter dans une même application, j'ai décidé de charger dynamiquement les bibliothèques de connexion et de tout invoquer par réflexion, par l'intermédiaire d'une API de proxies fondée sur java.lang.invoke (première fois que je pratique) et JCL (et son JarClassLoader).
Cela fonctionne toujours la première fois (je fais un petit programme de test, l'API n'étant que partiellement implémentée, juste pour valider que ça fonctionne). Mais j'obtiens une LinkageError ensuite, lors d'un autre test (même code), sur la création d'un handler(MethodHandle) sur une méthode : le plus souvent la seconde fois, mais j'ai eu un cas de tests où ça plantait à partir de la troisième fois (Je décris plus loin les 2 cas de tests). L'erreur de Linkage survient lors du lookup d'une méthode par MethodHandles.publicLookUp() : je ne sais pas si le problème vient de ma mauvaise utilisation de l'API java.lang.invoke ou est lié à ma mauvaise utilisation du JarClassLoader JCL, ou à l'environnement ou l'implémentation de la bibliothèque "dynamique", ou autre.
Voici la stacktrace :
Tout d'abord, j'ai un peu du mal à comprendre pourquoi le bootloader est cité dans l'histoire, et surtout comment pourrait-il avoir chargé une version de l'interface xxx/interfaces/IServer sachant qu'elle n'est pas dans le (son) classpath. A priori, de ce que je comprends, la classe java.lang.Object citée est celle de base pour le lookup de méthode : en quoi le classloader de cette classe doit-il intervenir dans la résolution des types de la méthode recherchée.Citation:
Caused by: java.lang.LinkageError: loader constraint violation: when resolving method "xxx.impl.common.ServerFactory.getRemoteServer(Ljava/lang/String;)Lxxx/interfaces/IServer;" the class loader (instance of <bootloader>) of the current class, java/lang/Object, and the class loader (instance of xxx/engine/db/internal/RemoteClientJarClassLoader) for the method's defining class, xxx/impl/common/ServerFactory, have different Class objects for the type xxx/interfaces/IServer used in the signature
at java.lang.invoke.MethodHandleNatives.resolve(Native Method)
at java.lang.invoke.MemberName$Factory.resolve(MemberName.java:962)
at java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:987)
... 56 more
D'après les traces, les classes citées dans la stacktrace sont au moins bien chargées par le JarClassLoader JCL. Je comprends bien le problème d'incompatibilité des classes, mais en l'occurance, je ne vois pas pourquoi je devrais être compatible avec des classes d'un autre contexte qui n'est absolument pas censé manipuler les classes que je manipule. Est-ce que mon problème serait lié à l'environnement OSGi dans lequel mon application fonctionne (Eclipse Platform en l’occurrence) ? A noter, que j'ai déjà un autre composant qui fonctionne très bien, et autant de fois que nécessaire, même en cas d'exception, mais qui est beaucoup plus simple : un seul JAR, aucune des méthodes invoquées n'a de type de ce JAR en tant qu'argument ou type de retour, et je n'utilisais pas l'API java.lang.invoke, mais java.lang.reflect.
En tout cas, si quelqu'un voit où j'ai fait ce qu'il ne fallait pas, ou pas fait ce qu'il fallait, merci d'avance de m'en faire part.
Quelques précisions supplémentaires :
Chaque proxy est instancié par une fabrique utilisant le JarClassLoader en passant l'instance de classe dynamique, elle-même instanciée par réflexion. Pour me faciliter l'écriture des proxies, je peux passer, lors du lookup (de méthodes ou de constructeurs), la classe de proxy (ou l'instance selon la méthode), celle-ci étant adaptée au besoin (adaptClass() dans le code ci-après) en classe dynamique via une constante de la classe de proxy (voir pour exemple PROXIED_CLASS ci-après).
L'erreur relative à la stacktrace ci-dessus correspond à l'exécution du constructeur ci-après :
RemoteClienJarClassLoader est une extension de JarClassLoader (JCL). L'exception intervient lors de l'appel de la seconde ligne du constructeur ci-dessus. Les interfaces de mon API de proxy ont le même nom simple que celle du JAR dynamique, mais pas le même package.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
La méthode getMethod() :
Voici les 2 cas de tests :Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
- Celui qui fonctionne la première fois et plante dès la seconde
Code:
2
3
4
5
6
7
8
9
10
11
- Celui qui fonctionne la première fois, la seconde et plante dès la troisième
Code:
2
3
4
5
6
7
8
9
On voit que les 2 tests invoquent la méthode (getServer()) sur laquelle le lookup plante.
S'il y a besoin d'autres précisions, extraits de code... n'hésitez pas.
