Questions & Answers

[rkl]

Hallo Community,

wir haben das Problem, dass in einem if-Statement in einer unserer Klassen, über ein 'instance of' zu ermittlen versucht wird, ob die die vorhandene/aktuelle Connection eine sog. WebeditConnection ist, ein NoClassDefFoundError fliegt.

Die Klasse WebeditConnection ist Bestandteil des fs-webrt.jar

In diesem Zusammenhang die Frage: Wie ist diese aus Sicht des JavaClient Classloaders verfügbar?

Das Ganze passiert unter FS4.2 R4 build 434.

Hat sonst noch jemand Effekte, die auf Classloading-Probleme zurückzuführen sind?

Danke & Sonnige Grüße aus Stuttgart

R. Kloppmann

[Peter_Jodeleit]

Das ist kein Classloading-Problem, die Klasse ist im JavaClient nicht verfügbar. Muss sie auch nicht, da sie kein Teil der FS-API ist.

[rkl]

Ganz so ist das nicht korrekt. Die Klasse ist lediglich kein Bestandteil der FS Access API.

Da diese jedoch zumindest bei uns bereits seit einiger Zeit verwendet wird und erst seit kurzem Probleme bereitet sei die Frage erlaubt... 😉

[gockel]

Die Klasse ist lediglich kein Bestandteil der FS Access API.

Da diese jedoch zumindest bei uns bereits seit einiger Zeit verwendet wird und

erst seit kurzem Probleme bereitet sei die Frage erlaubt... 😉

Und damit können Sie auch in keinerlei Hinsicht die Erwartungshaltung haben, dass die Verwendung einer solchen Klasse nach einem Update der FS-Version noch funktioniert.

Man sollte an dieser Stelle dann eher mal über die fachliche Notwendigkeit für die Verwendung der Klasse sprechen.

[king]

Wenn wir Sie richtig verstehen, sind damit nur Klassen der "fs-access.jar"-API in den Clients wie Java-/WebClient verfügbar? Werden diese über einen individuellen ClassLoader (Remote-ClassLoader) dynamisch vom FS-Server nachgeladen, da sie nicht direkt im "fs-client.jar" enthalten sind?

Im Paket "fs-client.jar" ist die Klasse "de.espirit.firstspirit.client.webedit.WebeditConnection" auch nicht direkt enthalten (was ja potentiell möglich gewesen wäre). Wir finden sie aktuell nur in der "fs-webrt.jar". Damit müsste Sie, um sie überhaupt auf den Clients verfügbar zu machen über einen Remote-ClassLoader nachgeladen werden.

Jetzt stellt sich uns die Frage: wie können Klassen aus nicht gesicherten API-Bereichen (wie der "fs-webrt.jar") in Projektlösungen von FirstSpirit überhaupt verwendet werden? Sauber ist das ja auch nicht!

[gockel]

Damit müsste Sie, um sie überhaupt auf den Clients verfügbar zu machen über einen Remote-ClassLoader nachgeladen werden.

Laut dem initialen Posting von Herrn Kloppmann ist der Kontext über den wir hier reden der JavaClient .

Also ein Kontext, der mit dem fs-webrt.jar überhaupt nichts zu tun hat. Der JavaClient benötigt die Klasse WebeditConnection nicht. Es besteht also überhaupt keine Notwendigkeit diese Klasse "den" Clients (JavaClients) verfügbar zu machen.

Jetzt stellt sich uns die Frage: wie können Klassen aus nicht gesicherten API-Bereichen (wie der "fs-webrt.jar") in Projektlösungen von FirstSpirit überhaupt verwendet werden?

Ich wiederhole meine Frage nach der fachlichen Anforderung gerne nochmal.

Was ist die fachliche Anforderung, innerhalb der Klasse von Ihnen, die aus dem JavaClient heraus verwendet wird, gegen die Klasse WebeditConnection (aus fs-webrt.jar) zu prüfen?