Help

Questions & Answers

SOLVED
Jump to solution
hbarthel
New Responder
‎12-02-2015 09:11 AM

Remote class loading

Jump to solution

Hallo,

wir haben hier eine webapp auf einem separaten Tomcat, die mittels fs-access.jar auf einen FirstSpirit-Server zugreift. Im Einsatz ist ein Workflow, der Skripte verlinkt, die ein Executable aufrufen. Wir waren nun ganz überrascht, dass der Code auf unserem Tomcat ausgeführt wird und nicht auf dem FS-Server. Hier der Stacktrace vom Breakpoint in einem static initializer unserer Klasse "StartEditingExecutable", die allerdings gar nicht in der webapp enthalten ist:

stacktrace_fs_module.png

Das heißt, die Klassen werden irgendwie über einen remote class loading-Mechanismus über WorkflowAgentImpl - TaskImpl - ScriptImpl - ClassCallerEngine vom ModuleClassesLoader geladen.

Nun die Fragen:

1. Gibt es dazu Dokumentation?

2. Kann man erzwingen, dass dieser Code auf dem FS-Server ausgeführt wird und nicht fern?

Besten Dank und viele Grüße,

Heiko

Labels
1 Solution

Accepted Solutions
bIT_sosswald
Returning Responder
‎12-03-2015 02:55 AM

Jump to solution

Hallo Heiko,

den Einsatz einer WebApp die Executables ausführt habe ich bisher noch nicht umgesetzt.

Aber bei der FS-Modulentwicklung gibt es meiner Meinung nach eine Faustregel: Public- und Library-Komponenten (und die Executables werden wohl eine Public-Komponente sein) werden da ausgeführt wo sie aufgerufen werden. Will man erzwingen, dass der Code auf dem FS-Server ausgeführt wird ist eine Service-Komponente die richtige Wahl.

Ich mache es in meinem Modulen, die teilweise aus Skripten aus dem SiteArchitekt heraus aufgerufen werden, immer wie folgt:

  1. Ein Skript ruft ein Executable auf (um unnötigen BeanShell Code im Skript zu vermeiden und echtes Java zur Verfügung zu haben)
  2. Das Executable holt sich den Service und ruft diesen auf
  3. Der Service macht die eigentliche Arbeit auf dem FS-Server und gibt evtl. das Ergebnis zurück
  4. Wenn Ergebnisse zurückgegeben werden, verarbeitet das Executable / Skript etc. dieseweiter

Damit erzwinge ich, dass die teilweise rechenintensiven Operationen auf dem FS-Server und nicht im Executable im CLient ausgeführt werden.

Evtl. ist es ja auch ein Weg für deine WebApp einen FS-Service aufzurufen.

PS: Eine Doku zum Thema Classloading findest du im PDF" FirstSpirit Handbuch für Entwickler (Komponenten)". (http://[FS-Host]/help/odfs/Dokumentation/Fuer-Entwickler/)

Grüße

Sandro

View solution in original post

1 Reply
bIT_sosswald
Returning Responder
‎12-03-2015 02:55 AM

Jump to solution

Hallo Heiko,

den Einsatz einer WebApp die Executables ausführt habe ich bisher noch nicht umgesetzt.

Aber bei der FS-Modulentwicklung gibt es meiner Meinung nach eine Faustregel: Public- und Library-Komponenten (und die Executables werden wohl eine Public-Komponente sein) werden da ausgeführt wo sie aufgerufen werden. Will man erzwingen, dass der Code auf dem FS-Server ausgeführt wird ist eine Service-Komponente die richtige Wahl.

Ich mache es in meinem Modulen, die teilweise aus Skripten aus dem SiteArchitekt heraus aufgerufen werden, immer wie folgt:

  1. Ein Skript ruft ein Executable auf (um unnötigen BeanShell Code im Skript zu vermeiden und echtes Java zur Verfügung zu haben)
  2. Das Executable holt sich den Service und ruft diesen auf
  3. Der Service macht die eigentliche Arbeit auf dem FS-Server und gibt evtl. das Ergebnis zurück
  4. Wenn Ergebnisse zurückgegeben werden, verarbeitet das Executable / Skript etc. dieseweiter

Damit erzwinge ich, dass die teilweise rechenintensiven Operationen auf dem FS-Server und nicht im Executable im CLient ausgeführt werden.

Evtl. ist es ja auch ein Weg für deine WebApp einen FS-Service aufzurufen.

PS: Eine Doku zum Thema Classloading findest du im PDF" FirstSpirit Handbuch für Entwickler (Komponenten)". (http://[FS-Host]/help/odfs/Dokumentation/Fuer-Entwickler/)

Grüße

Sandro