Remote-Debugging ItelliJ Idea
Author: tzumtobel
Publication Date: 9/27/2017 9:07
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
Tags: debugging, fsm, modulentwicklung, remote debugging
-
Author: mbergmann - 9/27/2017 10:25
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
0 -
Author: tzumtobel - 9/27/2017 10:32
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=
0 -
Author: mbergmann - 9/27/2017 11:01
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
0 -
Author: tzumtobel - 9/27/2017 11:17
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ß
0 -
Author: mbergmann - 9/27/2017 11:29
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
0 -
Author: tzumtobel - 9/27/2017 11:54
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ß
0 -
Author: mbergmann - 9/27/2017 12:10
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
0 -
Author: tzumtobel - 9/27/2017 12:19
Hallo Michael,
okay, dann sieht das ganze natürlich anders aus :smileyhappy:
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!
0 -
Author: mbergmann - 9/27/2017 12:31
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
0 -
Author: tzumtobel - 9/27/2017 12:50
Hallo Michael,
aktuell öffne ich ein Dialog-Fenster um dem User während der Laufzeit ein Feedback zum Status der Migration geben zu können.
Da bekam ich als Auftrag gerade schon eine "java.awt.HeadlessException", das liegt dann wohl an dem JDialog :smileyhappy:
Darauf kann ich in Zukunft aber auch verzichten.
Die Variante mit dem SA im Debug mode klingt super, das werde ich jetzt mal ausprobieren und mich anschließend nochmal hier melden.
Gruß
0 -
Author: tzumtobel - 9/27/2017 13:36
Hallo Michael,
das mit dem Client Debugging hat wunderbar geklappt, meine IDE geht stoppt bei den Breakpoints und ich kann nun endlich debuggen :smileyhappy:
Nur nochmal zum Verständnis für mich: wenn ich meine Klasse nun serverseitig ausführen lassen möchte, müsste ich entweder per CMS_RENDER im Template oder aber per Script im Auftrag arbeiten korrekt? Und dann muss ich auch wieder auf die Remote-Debugging Konfiguration zurückgreifen, oder?
Und wenn ich es weiterhin per FS-Script initialisiere, verwende ich die Client-Debugging Variante, korrekt?
Macht es denn in der Performance einen großen Unterschied, bzw. sollte ich bei komplexeren Anwendungen auf serverseitige Ausführung umstellen?
Viele Grüße und vielen Dank, hat mir sehr geholfen und die weitere Entwicklung wird dadurch signifikant schneller sein :smileyhappy:
0 -
Author: mbergmann - 9/27/2017 13:57
Hallo Thomas,
freut mich dass es klappt :-)
Zu Deinen Fragen: Ja, genau. Bis auf das mit dem CMS_RENDER, das war nur ein Beispiel wo eine Executable auf dem Server läuft. Macht in Deinem Kontext aber keinen Sinn. Von daher wäre der Auftrag dann der richtige Weg.
Man kann das Ganze auch so aufbauen dass beides geht. Zum Entwickeln nimmt man dann die Variante mit dem SA im Debug-Modus und wenn das soweit alles klappt baut man es in einen Auftrag ein. Das geht natürlich nicht immer, insbesondere wenn man etwas mit Nutzer-Interaktion hat.
Es gibt natürlich noch die Variante, direkt aus der IDE heraus eine Verbindung zu FS aufzubauen (Stichwort ConnectionManager). Das wäre dann quasi eher eine Applikation. Damit kann man noch einfacher testen weil man nicht dauernd den Client hochfahren muss.
Von der Performance her hängt viel an der Kommunikation. Alles was im Client läuft, redet natürlich mit dem FS-Server was durchaus einiges an Performance kosten kann - insbesondere wenn es um viele und/oder große Objekte geht. Theoretisch gibt es auch noch das Risiko, dass bei einem Verbindungsabbruch oder auch Client-Absturz u.U. ein inkonsistenter Zustand bestehen bleibt (im Sinne von "irgendwie nur halb fertig geworden"). Lang laufende Sachen würde ich darum produktiv immer eher über einen Auftrag machen - aber zum Entwickeln / Testen eine direkte Verbindung bzw. Debug-SA nutzen.
Viele Grüße
Michael
0
Please sign in to leave a comment.
Comments
12 comments