tldr: You can try tweaking the command line like this:
spring-boot:run -Dspring-boot.run.fork=false
Explanation:
When running the application in debug mode, the IntelliJ debugger attaches to the Java process that it starts itself (by appending the appropriate parameters, -agentlib:jdwp
etc, to the Java command line).
Quite often, these Java processes might then fork a new instance, which is not getting the same parameters, and because it is in a separate process, is not connected to the debugger. This can be confusing.
The spring-boot:run
Maven goal, in addition to forking a new JVM, creates even more confusion, because it sometimes does fork and sometimes doesn't, depending on the options it gets, among other things. Some of this can be found in the documentation, but it's not always obvious.
You should first check whether the Java process actually is being debugged at all. When you start the application from IntelliJ, you will see messages scrolling by in the Run / Debug tab. At the top, there's the command line that is being executed. It should contain the debugger parameters (-agentlib:jdwp
etc) and it should be followed by a message saying "Connected to the target VM", which is the debugger confirming that it has contact.
Next, if you are unsure if the JVM has been forked, you can check the process list in your OS, for example under MacOS and *nix you can use ps aux | grep java
. The Java processes typically have a giant parameter list, most of which is the class path. The actual application being run is at the very end of the command line. If the JVM was forked, you have the process running the Maven goal, and another one running the Spring application. Then your debugger will be connected to the process you are not interested in, and your breakpoints won't work.
To stop spring-boot:run
from forking, you can use the fork
parameter above.
bootRun
option there with the right-click – Andrew Tobilko