Questions & Answers

[odegener]

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

[odegener]

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.

[mbergmann]

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

[odegener]

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

[mbergmann]

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

[odegener]

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

Viele Grüße,

Oliver

[mbergmann]

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