ClassLoader dynamique (JCL) et MethodHandle : LinkageError

**joel.drigo** · 29/03/2016, 18h41

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 :

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

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.
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 :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public class ServerFactoryImpl extends AbstractRemoteLibraryClassProxy implements IServerFactory {
 
	public static final String PROXIED_CLASS = "xxx.impl.common.ServerFactory"; //$NON-NLS-1$
 
	private static final String GET_REMOTE_SERVER = "getRemoteServer"; //$NON-NLS-1$	
 
	private final MethodHandle getRemoteServerMethod;
 
	public ServerFactoryImpl(RemoteClientJarClassLoader classLoader, Object instance) throws CoreException {
		super(classLoader, instance);
		getRemoteServerMethod = classLoader.getMethod(instance, GET_REMOTE_SERVER, ServerImpl.class, String.class);
	}
 
        public IServer getServer(String url) throws CoreException {
		try {
			Object remoteServer = getRemoteServerMethod.invoke(url);
			return new ServerImpl(classLoader, remoteServer);
		} catch(CoreException e) {
			throw e;
		} catch (Throwable e) {
			throw new CoreException(XXXActivator.createErrorStatus("Cannot get server", e)); //$NON-NLS-1$
		}
	}

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.

La méthode getMethod() :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public MethodHandle getMethod(Object instance, String methodName, Class<?> returnType,
			Class<?>...types) throws CoreException { 
 
		try {
			return PUBLIC_LOOKUP.bind(instance, methodName, 
					MethodType.methodType(
							adaptClass(returnType),
							Arrays.stream(types).map(t-> uncheckedAdaptClass(t)).toArray(n-> new Class[n])));
		} catch ( RaiseException e ) {
			throw e.raise(t-> new CoreException(XXXActivator.createErrorStatus("Cannot get method " + methodName + " in class " + instance.getClass(),t)), //$NON-NLS-1$ //$NON-NLS-2$
					CoreException.class);
		} catch (NoSuchMethodException | IllegalAccessException e ) {
			throw new CoreException(XXXActivator.createErrorStatus("Cannot get method " + methodName + " in class " + instance.getClass(), e)); //$NON-NLS-1$ //$NON-NLS-2$
		}
 
	}

Voici les 2 cas de tests :

Celui qui fonctionne la première fois et plante dès la seconde

Code :

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

1
2
3
4
5
6
7
8
9
10
11
try (DAOHandler dao = xxxProject.getDAOHandler()) { // DAOHandler encapsule le JarClassLoader, ainsi qu'une instance de proxy (ServerFactory=>ServerFactory)
    System.out.println(dao);
    IServer server = dao.getServer(); // invoque indirectement ServerFactory pour obtenir un proxy IServer=>IServer (en fait l'invocation est faite dans le constructeur et l'instance est stockée, getServer() se comportant que comme un getter).
    System.err.println(server); 
    ISession session = dao.getServer().getSession("admin","admin"); // invoque directement IServer pour obtenir un proxy ISession=>ISession
    System.out.println(session);
} catch (CoreException e) {
    e.printStackTrace();
} catch (IOException e1) {
    e1.printStackTrace();
}

Celui qui fonctionne la première fois, la seconde et plante dès la troisième

Code :

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

1
2
3
4
5
6
7
8
9
try (DAOHandler dao = xxxProject.getDAOHandler()) { // DAOHandler encapsule le JarClassLoader, ainsi qu'une instance de proxy (ServerFactory=>ServerFactory)
    System.out.println(dao);
    IServer server = dao.getServer(); // invoque indirectement ServerFactory pour obtenir un proxy IServer=>IServer
    System.err.println(server); 
} catch (CoreException e) {
    e.printStackTrace();
} catch (IOException e1) {
    e1.printStackTrace();
}

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.

**tchize_** · 29/03/2016, 19h14

tu pourrais donner la stacktrace complète? Les informations sont trop parcelaires pour voir ce qui se passe.

ServerFactoryImpl il est chargé par quel classloader?

AbstractRemoteLibraryClassProxy et IServerFactory tu peux nous donner leur classTree?

Si le bootloader te dis qu'il vois xxx/interfaces/IServer, c'est que ça fais partie de son classpath.

Tu peux éventuellement juste avant l'appel faire un

Class.forName("xxx/interfaces/IServer") et t'assurer que ça pête bien?

Note que puisque le bootloader vois xxx/interfaces/IServer, affiche Class.forName("xxx/interfaces/IServer").getProtectionDomain().getCodeSource() pour savoir où il a été le piocher.

**tchize_** · 29/03/2016, 19h18

autre chose. A priori si j'ai bien compris le principe, tu télécharge des jars pour les ajouter à un JCL custom. Tu lé téléchargerais pas dans un endroit où le classloader principal irait ensuite les piocher?

**joel.drigo** · 29/03/2016, 19h45

Envoyé par tchize_

tu pourrais donner la stacktrace complète? Les informations sont trop parcelaires pour voir ce qui se passe.

Voilà :

org.eclipse.core.runtime.CoreException: Cannot instanciate class xxx.engine.db.internal.stub.ServerFactoryImpl

at xxx.engine.db.internal.RemoteClientJarClassLoader.newInstance(RemoteClientJarClassLoader.java:148)
at xxx.engine.db.internal.Connector.<init>(Connector.java:29)
at xxx.engine.db.DAOHandler.<init>(DAOHandler.java:22)
at xxx.project.WxmProject.getDAOHandler(WxmProject.java:84)
at xxx.engine.TestHandler.execute(TestHandler.java:30)
at xxx.engine.TestHandler.execute(TestHandler.java:21)
at xxx.handlers.AbstractProjectHandler.execute(AbstractProjectHandler.java:32)
at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:295)
at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:90)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:252)
at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:234)
at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:132)
at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.execute(HandlerServiceHandler.java:152)
at org.eclipse.core.commands.Command.executeWithChecks(Command.java:493)
at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:486)
at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:210)
at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.executeItem(HandledContributionItem.java:799)
at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.handleWidgetSelection(HandledContributionItem.java:675)
at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.access$7(HandledContributionItem.java:659)
at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem$4.handleEvent(HandledContributionItem.java:592)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4362)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1113)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4180)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3769)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1127)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1018)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:156)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:654)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:598)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:139)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:669)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:608)
at org.eclipse.equinox.launcher.Main.run(Main.java:1515)
at org.eclipse.equinox.launcher.Main.main(Main.java:1488)

Caused by: org.eclipse.core.runtime.CoreException: Cannot get method getRemoteServer in class class xxx.impl.common.ServerFactory

at xxx.engine.db.internal.RemoteClientJarClassLoader.getMethod(RemoteClientJarClassLoader.java:177)
at xxx.engine.db.internal.stub.ServerFactoryImpl.<init>(ServerFactoryImpl.java:23)
at xxx.engine.db.internal.RemoteClientJarClassLoader.newInstance(RemoteClientJarClassLoader.java:146)
... 51 more

Caused by: java.lang.IllegalAccessException: no such method: xxx.impl.common.ServerFactory.getRemoteServer(String)IServer/invokeSpecial

at java.lang.invoke.MemberName.makeAccessException(MemberName.java:869)
at java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:990)
at java.lang.invoke.MethodHandles$Lookup.resolveOrFail(MethodHandles.java:1382)
at java.lang.invoke.MethodHandles$Lookup.bind(MethodHandles.java:1146)
at xxx.engine.db.internal.RemoteClientJarClassLoader.getMethod(RemoteClientJarClassLoader.java:169)
... 53 more

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

Envoyé par tchize_

ServerFactoryImpl il est chargé par quel classloader?

Par la classloader standard, soit EquinoxClassLoader (Il s'agit d'une classe locale de mon plug-in et qui me sert de proxy (toutes les classes machinimpl sont dans ce cas, toutes celles dans les packages xxx/engine/db/internal/ également)

Envoyé par tchize_

AbstractRemoteLibraryClassProxy et IServerFactory tu peux nous donner leur classTree?

Classe (abstraite) xxx.engine.db.internal.AbstractRemoteLibraryClassProxy extends Object implements xxx.engine.db.IRemote
IRemote c'est une interface sans méthode qui me sert de "marqueur" (toutes mes classes de proxy implémenteront forcément cette interface)
Inteface xxx.engine.db.IServerFactory extends xxx.engine.db.IRemote

Envoyé par tchize_

Si le bootloader te dis qu'il vois xxx/interfaces/IServer, c'est que ça fais partie de son classpath.

Et bien, je ne vois pas comment. Et surtout il n'y aucune raison. En tout cas, si j'essaye d'importer la classe, je ne peux pas compiler.
J'ai bien un ClassNotFound si je fais un Class.forName() (déjà testé).
Mais je vais tenter le test avec le Class.forName() juste à la fin de mon test, avant de fermer le JarClassLoader et de décharger les classes. Et en ajouter un juste avant le lookup de la méthode aussi.

Envoyé par tchize_

autre chose. A priori si j'ai bien compris le principe, tu télécharge des jars pour les ajouter à un JCL custom. Tu lé téléchargerais pas dans un endroit où le classloader principal irait ensuite les piocher?

Non. Pour être factuel et précis, je réalise un plug-in JDT/WTP pour Eclipse, pour pouvoir développer avec une application de type JEE. Le principe de base est la surcharge d'un projet Dynamic Web avec une nature particulière (un truc Eclipse). Donc, en gros il s'agit d'ajouter des fonctions spécifiques à un projet Dynamic Web. L'application est installée dans le dossier WebContent et le dossiert web-inf/lib contient des jars.
Certaines fonctionnalités ne peuvent être exécutées qu'en communication avec le serveur, et ceci peut se faire avec une bibliothèque spécifique (HTTP) fournie également dans le web-inf/lib (elle peut fonctionner en server distant, ou en serveur locale).
Comme chaque projet xxx peut être constitué sur une version différente de serveur, ayant sa propre version de lib, lorsque je fais une action qui doit communiquer avec le serveur, je vais chercher le contexte de projet, je détermine le dossier webcontent, et j'utilise les jars ad hoc qui s'y trouvent.
Normalement, le plug-in et l'application web qui s'exécute dans le tomcat ne partagent pas ni de jars, ni de dossier, mais ce n'est pas impossible, c'est sûr. Je ne sais pas si Eclipse package ses plug-ins pour tester (en particulier en debug, car je suis en mode debug pour tester), mais si c'est le cas, je ne peux même pas ajouter de jar au plug-in, puisque c'est un jar à ce moment.

**joel.drigo** · 29/03/2016, 19h56

Envoyé par joel.drigo

Mais je vais tenter le test avec le Class.forName() juste à la fin de mon test, avant de fermer le JarClassLoader et de décharger les classes. Et en ajouter un juste avant le lookup de la méthode aussi.

ClassNotFoundException dans les deux cas.

Je vais remplacer les MethodHandle par de la réflexion à "l'ancienne", pour voir si ça ne vient pas de là.

**tchize_** · 29/03/2016, 22h10

Ha c'est du eclipse. Je ne connais pas trop les classloader dans eclipse, mais ils me semblent qu'ils obéissent à leurs propres règles dans une modèle OSGi, non ?

**joel.drigo** · 29/03/2016, 22h18

Envoyé par tchize_

Ha c'est du eclipse. Je ne connais pas trop les classloader dans eclipse, mais ils me semblent qu'ils obéissent à leurs propres règles dans une modèle OSGi, non ?

C'est le cas oui. Est-ce que tu penses que ça pourrait rendre incompatible le classloader JCL ?
J'ai commencé à jeter un coup d'œil pour voir si je pouvais faire ça avec OSGi, mais la doc est collossale et je n'ai pas vraiment le temps de creuser.

ClassLoader dynamique (JCL) et MethodHandle : LinkageError

Java

Vue hybride

Discussions similaires

Partager

Partager