Ausführung von Executables über WE_API.Common schlägt fehl (ClassNotFoundException)
Author: odegener
Publication Date: 4/4/2019 10:49
Hallo zusammen,
bei der Entwicklung einer Erweiterung für den ContentCreator bin ich auf das Problem gestoßen, dass ich über WE_API.Common.execute(...) ausschließlich Skripte, aber keine Executables ausführen kann.
Der Aufruf erfolgt entsprechend der API-Dokumentation über die class:<FULLY_QUALIFIED_CLASS_NAME> Syntax:
WE_API.Common.execute("class:com.monday.executables.MyExecutable", "", function(result) { alert(result) });
Das Server-Log liefert eine ClassNotFoundException:
java.lang.IllegalStateException: loading of public type 'com.monday.executables.MyExecutable' failed, type de.espirit.firstspirit.access.script.Executable
[...]
Caused by: java.lang.ClassNotFoundException: com.monday.executables.MyExecutable
Rufe ich über die WE_API hingegen ein Skript auf (über die script:<SCRIPT_UID> Syntax), dass auf die Executable verweist ( #!executable-class com.monday.executables.MyExecutable ), funktioniert der Aufruf und ich bekomme das Ergebnis in einem Alert.
Die Executables werden von meinem Modul mit scope="server" bereitgestellt, sodass ich mir die ClassNotFoundException nicht erklären kann. Müssen die Executables zusätzlich als Modul-Dependency der ContentCreator-WebApp installiert werden?
Viele Grüße,
Oliver Degener
Tags: content-creator, executable, we_api
-
Author: odegener - 4/4/2019 10:52
Ich sehe gerade, dass hier ein ähnliches Problem geschildert wird: https://community.e-spirit.com/message/22059#22059
Ich hätte jedoch vermutet, dass es ausreicht, die Executables im Server-Scope bereitzustellen.
0 -
Author: mbergmann - 4/5/2019 19:54
Hallo Oliver,
bei CC-Erweiterungen sollten die Klassen bzw. deren jars immer in der CC-WebApp bereitgestellt werden.
In welchem Webserver läuft denn der CC? Internal Jetty, Jetty-Modul oder Tomcat?
Das Executable sollte immer auch als <PUBLIC>-Komponente in der module.xml deklariert werden.
Versuch dann auch mal
class:NAME_DES_EXECUTABLES
d.h. nicht den FQCN sonder den Namen der PUBLIC-Komponent.
Viele Grüße
Michael
0 -
Author: odegener - 4/8/2019 13:01
Hallo Michael,
danke für deine Antwort!
Wenn ich die Klasse direkt in der CC-Erweiterung bereitstelle, schlägt die Installation des Moduls fehl:
Fehler beim Installieren der FSM-Datei!
java.io.FileNotFoundException: classes not found: [com/monday/webforms/webedit/executables/TestExecutable.class]
FSVersion=5.2.190306.78131#4486;JDK=1.8.0_202 64bit Oracle Corporation;OS=Mac OS X 10.14.3 x86_64;Date=08.04.2019 13:26:14
Der CC läuft aktuell im FirstSpiritJetty. Da es sich jedoch um Produktentwicklung handelt, müssen prinzipiell alle Deploymentformen unterstützt werden.
Wir setzen jetzt vorerst ein Skript ein, dass auf die Executable, die durch unsere global zur Verfügung gestellte JAR bereitgestellt ist, verlinkt. Das funktioniert soweit.
Im aktuellen Fall müssen wir aus dem Executable auch ein Formular anzeigen ( context.showForm() ), wäre das ohne den Umweg über ein Template Script überhaupt möglich?
Viele Grüße,
Oliver
0 -
Author: mbergmann - 4/9/2019 23:32
Hallo Oliver,
ist das jar in dem die Klasse ist denn auch als web-resource in der WebApp-Komponente deklariert?
Bei WebApp-resources gibt es kein scope bzw. es wirkt nicht da FirstSpirit dort keine Kontrolle über das Classloading hat.
Beim Jetty ist das so eine Sache... Weil der „im“ FirstSpiri-läuft kann es sein dass der Klassen im server scope sieht (wenn ich es richtig im Kopf habe). Wenn das dann später in einem Tomcat läuft kann es darum sein, dass das dann nicht mehr geht.
context.showForm() geht natürlich nur bei Script-Objekten. Allerdings kannst Du ein Formular auch „on the fly“ definieren über den FormsAgent bzw. die ShowFormDialogOperaten. Ist ein wenig aufwendiger aber dafür brauchst Du kein Scrip wodurch das Modul „in sich abgeschlossener“ ist.
Viele Grüße
Michael
0 -
Author: odegener - 4/10/2019 12:30
Moin Michael,
das JAR ist als web-resource unserer CC-Erweiterung eingetragen. Anscheinend wird es aber nicht bei der Validierung des Moduls berücksichtigt, sodass die FileNotFoundException bzgl. der Public-Component auftritt. In unserem aktuellen Workaround legen wir eine "leere" Executable mit identischem Namen in unser server-scoped Executable-jar um die Validierung zu bestehen. Beim Aufruf der Executable wird dann die tatsächliche Klasse ausgeführt - dies kann natürlich nur ein temporärer Fix sein.
Vielen Dank für den super Tipp mit dem FormsAgent und der ShowFormDialogOperation. Da die Executable parametirisierbar ist, haben wir das Formular sowieso schon "on the fly" definiert. Die Umstellung auf den FormsAgent war also ein Klacks :smileyhappy:
Viele Grüße,
Oliver
0 -
Author: mbergmann - 4/11/2019 23:03
Hallo Oliver,
achja, ihr habt ja ein Multimodulprojekt... Da kann es tatsächlich sein dass FirstSpirit beim Registrieren der Public-Komponente nicht in die Web-Resources schaut. Da fällt
mir auch keine „schöne“ Lösung ein (außer ein TechSupport-Ticket zu erstellen - ist ja durchaus ein valider wenn auch wohl eher seltener Anwendungsfall).
Zum Unterschied zwischen „Script“ und „Executable“ per WE_API.Common.Execute ausführen aus Deinem Ursprungsposting: Da ist meines Wissens der Unterschied, dass das Script quasi vom eigentlichen FirstSpirit-Server angefordert wird wodurch der die „Auflösung“ durchführt. Wenn Du aber nach einer Klasse fragst, passiert alles „lokal“ in der CC-WebApp. So ungefähr jedenfalls ;-)
Viele Grüße
Michael
0
Vous devez vous connecter pour laisser un commentaire.
Commentaires
6 commentaires