Confirm. Problem was that I try to debug using maven run configuration. Switching to Application configuration type helps. I've spend half of a day on it (

I figured out what my issue was and I think the problem is specific to me and the nature of my application. Actually I should call it a self induced issue. Let me explain the nature of events.

1. I have been using eclipse to develop and have a local install of weblogic instance. My application needs coherence cache server and I have few other JVM parameters that I pass when starting the domain. Therefore I had added a line at the start of the $DOMAIN_HOME/bin/setDomainEnv.sh file like so

   JAVA_OPTIONS="- Dtangosol.coherence.distributed.localstorage=false -Dtangosol.coherence.wka=devmachine and blah blah blah

2. I switched to intellij and started working on this project and then configured the weblogic plugin and run configuration etc.

3. I noticed that intellij adds a JAVA_OPTIONS in the startup/connection tab in Run/Debug Configurations like so

4. However the JAVA_OPTIONS that was being passed by intellij was not being used by weblogic. I believe it was overridden with what was in the setDomainEnv.sh which is why I saw the following logs.

java version "1.6.0_65" Java(TM) SE Runtime Environment (build 1.6.0_65-b14-466.1-11M4716) Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-466.1, mixed mode) Starting WLS with line: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/java -client -Xms512m -Xmx512m -XX:MaxPermSize=256m -Dweblogic.Name=AdminServer -Djava.security.policy=/Users/dparupud/omw/oracle/middleware/weblogic_10.3.6/wlserver_10.3/server/lib/weblogic.policy -Dtangosol.coherence.distributed.localstorage=false -Dtangosol.coherence.wka=devmachine blah blah blah......

5. When I went and removed the JAVA_OPTIONS from setDomainEnv.sh and restarted the server from intellij I saw the following log

starting weblogic with Java version: java version "1.6.0_65" Java(TM) SE Runtime Environment (build 1.6.0_65-b14-466.1-11M4716) Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-466.1, mixed mode) Starting WLS with line: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/java -client -Xms512m -Xmx512m -XX:MaxPermSize=256m -Dweblogic.Name=AdminServer -Djava.security.policy=/Users/dparupud/omw/oracle/middleware/weblogic_10.3.6/wlserver_10.3/server/lib/weblogic.policy - agentlib:jdwp=transport=dt_socket,address=127.0.0.1:65501,suspend=y,server=n

Now the log showed that the jdwp agent was in action. I did notice that I did not see that particular log before I asked the Question on SO but I thought maybe IntelliJ was doing something inside the covers because JAVA_OPTIONS was being passed and intellij does not allow you to mess with that ( it is readonly).

I guess I can either pass all my jvm parameters either from intellij or add the jdwp agent info in the setDomainEnv.sh.

Now I am able to debug.

EDIT: it does not work anymore from Spring Boot 3+. See Ruik's comment

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.

Thanks to the suggestion from https://stackoverflow.com/a/47064387/509565 I've worked out the solution:

1. Use spring-boot:run -Dspring-boot.run.fork=false as your laucher command line
2. Ensure that "Delegate IDE build/run actions to Maven" in "Build ...> Build Tools > Maven > Runner" settings is NOT checked

Edit:

It seems that this trick isn't working anymore (Intellij-Idea 2024.4.4, Java 17): you can always start the application from the @SpringBootApplication itself.

Did some searching through IntelliJ Help PDF:
Help Doc pg. 431

Their documentation Describes the checkmark as "Shown at run-time when the breakpoint is recognized by the debugger as set on an executable code line."

and the regular red dot as "Shown at design-time or during the debugging session when the class with such breakpoint is not yet loaded. "

So it would seem that the line you're adding the breaking point to never gets executed. You can try stepping up line by line through the class to make sure the class is not getting hung up somewhere.