Home/ Questions/Q 7589515
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-30T20:10:45+00:00

I’m struggling to debug an application that builds as a Sling bundle. The application

  • 0

I’m struggling to debug an application that builds as a Sling bundle. The application is almost entirely Groovy code (I have the Groovy Eclipse plug-in), and Eclipse (using Maven) is building the .jar and installing it in Sling without any problems.

However, it’s not able to debug. I have followed instructions to set up remote debugging, which I gather is necessary for debugging Sling apps – specifically, I launch Sling with the following command:

java -Xdebug -Xnoagent -Djava.io.tmpdir=/c/Users/nickgolding1/temp -Xmx1024m -Xrunjdwp:transport=dt_socket,address=30303,server=y,suspend=n -jar org.apache.sling.launchpad-6-SNAPSHOT-standalone.jar -p 8080

… and then set up a debug configuration in Eclipse, of type “Remote Java Application”, pointing to my project, Connection Type “Standard (Socket Attach)”, host localhost, port 30303. This configuration seems to start ok – at least, I don’t get any feedback suggesting it hasn’t – but breakpoints I set in the Groovy code don’t actually break execution of requests to the Sling app.

I’ve seen a couple of posts on various forums that show people having problems debugging Groovy code via the Remote Java App configuration, where they don’t have a problem with Java code. Unfortunately my app is all Groovy and no Java, so I can’t verify this is the case here.

Any thoughts appreciated!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    First, a suggestion. Set suspend=y in your Xrunjdwp:transport option. This will suspend in main and will give you a better idea as to whether or not your problem is with your debug options or the Groovy code.

    Now, on to something more complicated. Yes. There are some issues regarding debugging of remote Groovy code. The problem generally comes about when Groovy code is loaded dynamically. In this case the debug name often does not match the source name and the debugger does not know how to match the dynamically loaded class file with the original source code.

    One such problem is described here (and there are no doubt other places where similar things happen):
    https://jira.springsource.org/browse/SPR-7113

    So, my suggestion to you is that if possible you should ensure that your groovy code is pre-compiled before being sent to the server. (And also set suspend=y.)

    • 0