Questions & Answers

[tzumtobel]

Halo zusammen,

ich baue aktuell ein Modul.

Der FS Server läuft lokal und ich würde gerne das Remote-Debugging nutzen. Das FSM wird mit Ant gebaut.

Ich deploye das Modul und kann mich erfolgreich per Remote Debug Konfiguration auf localhost:50005 verbinden.

Das einzige Problem: der Debugger stoppt nicht und springt in die von mir gesetzten Breakpoints..

Hatte jemand ggf. bereits dieses / ein ähnliches Problem?

Was ich schon versucht habe:

• .idea Verzeichnis gelöscht, Projekt neu erstellt
• IntelliJ caches invalidated & restarted
• Modul mehrfach neu gebaut & deployed

LG

[mbergmann]

Hallo Thomas,

wie sehen denn die Einträge in der fs-wrapper.conf aus wo Du den Debug-Modus aktiviert hast?

Viele Grüße

Michael

[tzumtobel]

Hallo Michael,

ich habe folgende Einträge in der fs-wrapper.conf ergänzt:

# Java parameters for garbage collection

# set -Xmn to 40% of wrapper.java.maxmemory

wrapper.java.additional.12=-Xmn1600M

wrapper.java.additional.13=-XX:MetaspaceSize=500M

wrapper.java.additional.14=-XX:MaxMetaspaceSize=500M

wrapper.java.additional.15=-XX:InitialCodeCacheSize=128M

wrapper.java.additional.16=-XX:ReservedCodeCacheSize=128M

wrapper.java.additional.17=-XX:SurvivorRatio=1

wrapper.java.additional.18=-XX:SoftRefLRUPolicyMSPerMB=1

wrapper.java.additional.19=-XX:+DisableExplicitGC

wrapper.java.additional.20=-XX:+UseConcMarkSweepGC

wrapper.java.additional.21=-XX:+UseParNewGC

wrapper.java.additional.22=-XX:+CMSParallelRemarkEnabled

wrapper.java.additional.23=-XX:+CMSClassUnloadingEnabled

wrapper.java.additional.24=-XX:+NeverTenure

wrapper.java.additional.25=-XX:-UseLargePages

wrapper.java.additional.26=-Djava.rmi.dgc.leaseValue=3600000

wrapper.java.additional.27=-Xdebug

wrapper.java.additional.28=-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=50005

wrapper.java.additional.29=

wrapper.java.additional.30=

wrapper.java.additional.31=

wrapper.java.additional.32=

wrapper.java.additional.33=

wrapper.java.additional.34=

wrapper.java.additional.35=

[mbergmann]

Hallo Thomas,

sieht für mich erstmal gut aus. Was genau versuchst Du denn zu debuggen? Falls es um ein CC-Plugin geht - läuft der CC im internen Jetty?

Viele Grüße

Michael

[tzumtobel]

Hallo Michael,

es geht um ein Migrations-Script, welches ich als FirstSpirit Script angefangen habe zu entwickeln, nun aber aufgrund der Komplexität in ein Modul umgebaut habe.

Das FirstSpirit läuft lokal auf meinem Macbook.

Gruß

[mbergmann]

Hallo Thomas,

gute Entscheidung - Beanshell-Scripte haben meiner Meinung nach eigentlich nichts in FS-Projekten zu suchen 😉

Als was startest Du das denn genau? In einem Auftrag oder im Client? Ist das ein Plugin, ein Executable oder was sonst für ein Einstiegspunkt? Das Remote-Debugging hängt sich ja an den Server-Prozess. D.h. das Debugging funktioniert in dieser Form nur für serverseitig ausgeführten Code. Nicht alles was in einem Modul ist, läuft auf dem FS-Server 😉

Hört sich für mich fast so an als müsstest Du hier eher den SA im Debug-Modus starten. Zumindest wenn Du die Funktionalität über den SA startest.

Viele Grüße

Michael

[tzumtobel]

Hallo Michael,

ich habe aktuell in meiner (momentan noch einzigen) Klasse das Executable Interface implementiert und starte meine Klasse per Einzeiler Script im FirstSpirit:

#! executable-class

de.q4u.migration.Importer

Das würde dann nach meinem Verständnis auf dem Server laufen, oder liege ich da falsch?

Gruß

[mbergmann]

Hallo Thomas,

wenn Du mit diesem Einzeiler-Script eines meinst, dass Du unter "Scripte" angelegt hast und das über "Extras => Skript ausführen" startest: Ja, da liegst Du falsch 😉

Es kommt letztlich immer auf den "Einstiegspunkt" an bzw. "wie und von wo" eine Funktion angetriggert wird. Auch ein Executable KANN serverseitig ausgeführt werden. Das wäre z.B. der Fall

• im Rahmen eines Auftrages (wenn dort ein Skript-Task definiert ist mit #!executable-class...)
• wenn das Executable als Renderscript benutzt wird (also aus dem Template heraus mit $CMS_RENDER(script:"...")$)

In Deinem Fall ist es aber eine ganz "normale" clientseitig ausgeführte Funktion. Dass da letztlich eine Executable hinter steckt ist unerheblich.

Viele Grüße

Michael

[tzumtobel]

Hallo Michael,

okay, dann sieht das ganze natürlich anders aus

Gut zu wissen, vielen Dank für die Info!

Der einfachste Weg das Remote-(Server)-Debugging zum Laufen zu bringen wäre dann vermutlich nun der Weg über den Auftrag.

Ich würde also dann einen Auftrag erstellen und in dem Auftrag lediglich eine Aktion welche dann das Executable startet, oder?

Diesen Auftrag kann ich ja genau wie aktuell mein Script aus dem SiteArchitekt heraus starten oder wäre das dann wieder im Client Context? :smileygrin:

Hinzu kommt, dass eine serverseitige Ausführung bei der Komplexität des Codes vermutlich auch mehr Sinn macht (von der Performance her vermute ich?).

Viele Grüße und vielen Dank jetzt schon mal, hat mir sehr geholfen!

[mbergmann · Accepted solution]

Hallo Thomas,

das kommt drauf an... Wenn Du irgendeine Art von Benutzerinteraktion brauchst, funktioniert es nicht als Auftrag. Das einfachste wäre eher, einfach den SA im Debug-Modus zu starten. D.h. eine weitere Run config anlegen aber vom Typ "Application" mit der Main-Klasse de.espirit.firstspirit.client.CMSExplorer. Dafür muss die fs-client.jar im scope liegen und genau zur Server-Version passen.

Unter VM-Options kannst Du dann die folgenden Parameter nutzen:

-Dhost=localhost (FS host, in Deinem Fall ja localhost)

-Dmode=HTTP

-Dport=12345 (der Port, unter dem Du auch die FS Startseite aufrufst, NICHT der Debug-Port des Servers!)

-Dlogin=plain

-Dlogin.user=*****

-Dlogin.password=****

-Dlocale=de

-DdevMode=1

-Dproject="PROJEKTNAME"

Der Vorteil der Variante "SA im Debug mode" ist, dass Du das Modul nicht jedes Mal bei einer Änderung neu installieren musst um es zu testen. Beim start als "Debug" werden nämlich immer die LOKALEN Klassen benutzt. Macht das Entwickeln um einiges leichter. Wichtig ist nur, dass das Modul einmal auf dem Server ist (letztlich wegen der module.xml).

Viele Grüße

Michael