Classloading in Webanwendungen am Beispiel FirstSpirit u. WebSphere

Anwendungsfall:

Eine Webanwendung, die in WebSphere eine FirstSpirit-Connection hält, und über diese Verbindung einen Modul-Service mittels getService(„ServiceName“) remote vom FirstSpirit-Server lädt, wird unter Umständen eine ClassCastException werfen, da die Klasse des Services, die vom FirstSpirit-Server zurückgeliefert wird, von zwei verschiedenen Classloadern geladen wird. Die Klasse des Service, die zurückgeliefert wird, ist vom FirstSpirit-RemoteClassloader geladen worden und kann nicht auf die Klasse gecastet werden, die der Anwendung durch den WebSphere-Classloader (CompoundClassloader) bekannt ist.

Die Classloader-Hierarchie stellt sich in etwa wie folgt dar:

WebApp(CompoundClassloader) --> VM-Classloader

Im VM-Classloader liegt das fs-isolated-webrt.jar, unter WEB-INF liegt der Service und somit im WebApp-Classloader, dieser delegiert an VM-Classloader. Da die FirstSpirit-Connection (VM-Classloader) versucht, die Service-Klasse zu laden und nichts findet, lädt sie diese über den FirstSpirit-RemoteClassloader. Dieser wird in der Hierarchie zwischen WebApp und VM nicht erreicht und daher wird die Service-Klasse von zwei Classloadern geladen.

Lösung:

Das JAR der Modul-Service-Komponente und das FirstSpirit fs-isolated-webrt.jar müssen in diesem Fall an gleicher Stelle liegen, also entweder im VM-Classloader oder im WebApp-Classloader (WEB-INF/lib).