IntelliJ IDEA Debugger isn't working on a Grai

问题:

I can't debug my code in Intellij IDEA. When debug mode is active and running, but the breakpoints don't have that "v" checked that represents a valid and stoppable breakpoint.

See the image: http://prntscr.com/1w0owu.

I really search on the web for an answer. What I suppose to do?

回答1:

I have tried all mentioned here without success. The only helpful information is here.

In essence you should disable forked execution by adding the following to grails-app/conf/BuildConfig.groovy:

grails.project.fork = [
    test: false,
    run: false
]

Now debugging is available in IntelliJ IDEA Ultimate Edition v.12.1.6 just by ordinary Debug without Remote debugging. Tested on Grails 2.3.1, Java 1.7.0_45, Windows 7 64-bit.

回答2:

Try this:

In idea choose Edit configurations from list next to 'run' button. Then add Remote, choose your name and left default remote configuration settings. (port 5005 etc)

Run your app from console by using

grails run-app --debug-fork

In idea, choose your configuration from list and hit debug button when console display info:

Listening for transport dt_socket at address: 5005

回答3:

Since Grails 2.3, forked execution for several Grails commands (e.g. run-app, test-app) was introduced. If you just debug a Grails application from IntelliJ IDEA, the GrailsStarter process will be started with debug options on. The output on the IDEA console will be:

/usr/lib/jvm/default-java/bin/java -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:59935,suspend=y,server=n [...] /opt/idea-IU-133.330/lib/idea_rt.jar org.codehaus.groovy.grails.cli.support.GrailsStarter [...] run-app Connected to the target VM, address: '127.0.0.1:59935', transport: 'socket'

The application itself will be started in a separate process named ForkedTomcatServer. This is where your code runs and where your debugger should actually connect to.

To accomplish that, set debug: true in BuildConfig.groovy at the run configuration of grails.project.fork. Just run Grails now from IDEA (do not debug) and you will see the following line in the console when the application is ready to serve HTTP requests:

Listening for transport dt_socket at address: 5005

This is where you want to direct a separate remote run configuration to. As soon as your remote debugger connected, issue a HTTP request and debugging will work.

You can also disable forked execution for compile/test/run/war/console Grails commands entirely by setting the value associated with the command entry in grails.project.fork to false. But then you will lose the benefits for forked execution added in Grails 2.3.

回答4:

Debugging a grails (2.3+) application can be done in two ways.

1. Simple solution: disable debug

edit BuildConfig.groovy:

grails.project.fork = [
    war: [maxMemory: 768, minMemory: 64, debug: false, maxPerm: 256, fork ...
    run: [maxMemory: 768, minMemory: 64, debug: false, maxPerm: 256, fork ...

to

grails.project.fork = [
    war: [maxMemory: 768, minMemory: 64, debug: false, maxPerm: 256, fork ...
    run: false,

Pros:

• Simple to do (and get on with your development)

Cons:

• This removes the ability to perform runtime code replacement. This means that if you change code, it will no longer be picked up automatically and you will need to restart the application to see the changes. This can be very time consuming.

2. Involved solution: debug forked runtime

This is a somewhat more complex solution where you attach a debugger to a running grails application. It is described in more detail in this blog post.

After setup you have an extra run configuration that allows you to start up grails in forked mode, and yet another extra run configuration that allows you to debug that forked mode. The catch is that you are required to start both or it does not work.

Pros:

• You have both debugging and runtime code replacement
• This does not interfere with starting the application in normal mode. (i.e. you have extra options)

Cons:

• Setting up takes a little bit of time
• Starting up in debug mode requires is a more complex two step process (i.e. it takes longer)

Considerations

Solution 2 is mostly superior in the sense that it allows flexibility. I personally don't use debug a lot, so just start in normal mode. When I want to debug, I restart in debug mode.

Solution 1 is strictly better if you need to debug and also need to restart a lot. For instance when you are working on your domain classes or database setup in your BootStrap.groovy.

回答5:

Did you see this article? It details the how to step by step and got me past my problem.

http://mrhaki.blogspot.com/2013/12/grails-goodness-debugging-app-in-forked.html

回答6:

None of the other answers work for me on Grails 3.x in 2016 w/ Intellij 15.0.4. This does work for me:

Start grails in intellij with this command:

run-app  --debug-jvm

The console should output: "Listening for transport dt_socket at address: 5005 Grails application running at http://localhost:8080 in environment: development"

Now you can add a new configuration of type, "Remote", in Intellij. Then start it with its defaults.

And the new debug console window should write: "Connected to the target VM, address: 'localhost:5005', transport: 'socket'"

Done.

For those interested, the reference to grails 3.x documentation for starting a debuggable server is at section 2.8, runningAndDebuggingAnApplication:

http://grails.github.io/grails-doc/3.1.x/guide/gettingStarted.html#runningAndDebuggingAnApplication

"There are several ways to execute the Application class, if you are using an IDE then you can simply right click on the class and run it directly from your IDE which will start your Grails application. This is also useful for debugging since you can debug directly from the IDE without having to connect a remote debugger when using the run-app --debug-jvm command from the command line."

Important Note. When I tried the "simply right click on the class and run it directly from your IDE", the app did start. However, all requests I sent to my controller resulted in 500 errors with message: "Could not resolve view with name '/myendpoint' in servlet with name 'grailsDispatcherServlet'.

So, I reverted back to the instructions above.

回答7:

This is a very simple matter with Grails 3 and Idea (2016.1). There's no need to edit any files anymore, as recommended in the other answers.

For some reason, the debug icon in the Idea toolbar is greyed out, so you just have to navigate to your application entry point (the class that has the static void main method that starts the application), click on one of the run arrows in the left-hand gutter and select the Debug option.

From the JetBrains docs:

https://www.jetbrains.com/help/idea/2016.1/getting-started-with-grails-3.html

Debugging Grails 3 Application

IntelliJ IDEA lets you debug your Grails 3 application using Application.groovy.

In the Project tool window, open init directory and right-click the Application.groovy From the drop-down list select Debug Grails:'name' grails3_debug_app You can also use the editor to start the debugging process.

回答8:

Just three guesses:

Try running run-app, not run-war, both should work, but may be run-war just isn't working.

Or: try debugging remotely from console:

grails -debug run-app and then connect with Remote Debug in Idea.

Or, the last resort: downgrading your project to previous Grails versions could work. Yes, this is really annoying.

Hope this helps.

回答9:

I tested with intellij latest with Grails 2.3.4 on Mac Os x Lion.

Then I tried Igors's advice and it is working without forked mode.

grails.project.fork = [
    test: false,
    run: false
]

Please check for detail grails documentation

if you want to debug forked mode you should check following blog post explainsvery well.

http://blog.jdriven.com/2013/12/grails-goodness-debugging-app-forked-mode/

回答10:

This should not ever be the default configuration and only be left to the individual's choice. It's a freakin pain to do two configurations just get this thing running in debug mode in intellij. First you have to setup or modify the normal run configuration by adding "--debug-fork" after run-app. Second, you have to configure remote debugging , while accepting all the defaults. Then you have to run the run configuration, and when that's running, you run the debug configuration. What a pain. I prefer totally doing away with running without the forked option while developing. Time is money and I don't have time to monkey around. See Mr.HAKI explanation on doing this. http://blog.jdriven.com/2013/12/grails-goodness-debugging-app-forked-mode/

回答11:

Checkout this blog about Debugging Grails Forked Mode.