Is it possible to open 2 or more projects, in different IntelliJ instances, and debug across them?
For example:
I start debugging on Project A. Project A calls a method in Project B. I want my debugger to continue on Project B on the other window.
I know a way to debug across multiple maven projects, is to add all the projects to the same IntelliJ instance. But I would like to know if there is a way to do it, without adding all projects to the same instance. To break up the projects in its own IntelliJ windows.
Yeah it is possible
First create a remote debug configuration: Edit configuration -> Remote.
You will see a command line argument which you have to copy and paste it to the script that you made to run your java file.
Keep in mind, to make sure your Project B doesnt starting running before your turn your debugger on, change suspend=n to suspend=y.
Once your parent java file runs go to the secondary idea window and run the remote configuration that you created in first step. If everything is right, your code will stop at the breakpoint.
Related
I'm currently experiencing a problem with 'hot code replace' not working on Eclipse Galileo and JBoss 4.2.3.
Among other applications I'm running an exploded Java WAR on my local JBoss. The project from which it is build is managed by Maven. I build the project using the Maven goal war:exploded and then I copy that directory to JBoss with an ANT script.
When I'm now running the application and set a breakpoint anywhere in the code, Eclipse properly halts at that line in the debug mode.
But when I'm making a change to the source file and save it, Eclipse doesn't apply this change to the JBoss.
For example, when I make a normal code line into a comment, the debugger still steps over this comment as if it was regular Java code. Or when I remove a line, the debugger seems to get out of sync with the file and starts stepping over parenthesis.
But I'm not getting any 'hot code replace error'-messages either. It seems to me that Eclipse applies the changes to the source files, but doesn't apply it to the JBoss.
Are there any special preferences that have to be turned on in order to make hot code replace work? Or are there any mistakes in how I build and deploy the application to the JBoss?
I did not work with JBoss but I have two suggestions.
If you run your application in eclipse using the launch configuration
Is your "Project" - "Build Automatically" flag enabled?
If not, the code is not compiled and ignored t runtime.
When you debug an application in remote mode, you can not change the code, but you can change the value of parameters. (I think)
I had issues in a project with Maven and Eclipse. No errors were shown, but hot code replacement was not working. I read that "Build Automatically" has to be checked. I checked this and it still didnt work. I had some errors in other projects in my build path. I believe that was the error. When i researched, I found that the we had to uncheck the "Abort build when buildpath errors". I have given the details in the link below.
I had a similar problem with Open Liberty. Let me build on the accepted answer plus the answer from #user513365 (since a link there is now dead).
In my case I had two issues:
1. Build path errors
In my case my Incomplete build path was because I was using a Maven project with only src/main/java but without a src/test/java (so probably could have solved this by creating the latter).
But I was able to fix Hot Code Replace by going to Preferences -> Java -> Compiler -> Building and make one of two changes:
Either:
uncheck Abort build when build path errors occur OR
using the drop-down, change Incomplete build path from Error to Warning.
2. Make sure Eclipse-built classes are getting loaded
In my case my remote JVM was using a full JAR artifact from my local .m2 Maven repository. The accepted answer of enabling: "Project" - "Build Automatically" misses a subtlety here.
The Eclipse project build in my case is only going to do a hot code replace, if I do the Eclipse build after the debugger is attached. Yes, it will do the Eclipse build automatically, but if I restart my remote JVM and simply attach the debugger, it is still configured to load this class from my local .m2 JAR, and NOT pick up my local change.
FINAL NOTE ON THIS ANSWER VS. OTHER ANSWERS
If you are constantly changing the class that you are building automatically you might not notice the subtlety in point 2., and the accepted answer combined with the build path error mentioned in #user513365's answer will be all you need.
First check is the Project/Build automatically.
It may be also required to check the application server deployment configuration,
E.g. for JBoss, in Eclipse, in the Servers view, double click on the server and there is a Deployment Scanners section with two check boxes:
Add missing deployment scanners
Remove added deployment scanners before shutdown
https://docs.jboss.org/author/display/AS7/Deployment+Scanner+configuration
JBoss AS/ Deployment Scanner configuration
I just recently had this problem in Eclipse 2019-06 and found I had to uncheck the option in "Replace classfiles containing compilation errors" in Preferences->Java->Debug->Hot Code Replace group. All the other options there were checked.
Previous to doing that I was getting "Hot code replace failed - Delete method not implemented" despite my only change being to ass a System.out.println call.
As soon as I changed that option ( in the same debug session ) it started working for me.
I am running Netbeans 8.0.2 and I am trying to debug a web app. This app is a module in a larger suite. Normally just the parent gets compiled which set's up property values for db connections etc. So, that being said the web app I am trying to debug never gets built independently.
So, I want to be able to do right-click > debug without netbeans running the maven build (this will mess up the prop values).
I have the "Always perform build before running application" unchecked in the Run configuration. But every single time, it builds it anyways!
Is there something I'm missing? Or is there some bug in Netbeans?
Edit: I've also tried deleting the cache.
I know this is an old question which you probably (and hopefully) solved already. However, as I had the same problem and could not find an answer here, I want to share my solution to this problem for others.
My application also first built itself and then started debugging. I checked the run/debug configuration and they were fine. So I deleted the local maven repositories of all dependencies of my application and rebuilt them. Seems like NetBeans confused something with the dependencies and therefore rebuilt the application every single time again. After deleting and rebuilding the dependencies I was able again to debug the application without building it before.
I have a spring boot application. I use IntelliJ 13.
I want to launch my application in debug mode and debug it. I'm on Windows and I'd like to use shared memory. I would like to just be able to click the debug icon, or a single maven goal, and the application launches in debug mode and the IDE attaches the debugger. This is how I am used to debugging most of my java apps.
However, mixing spring-boot and IntelliJ seems to complicate things. IntelliJ seems to want to connect to the wrong process when I push the green "debug" button and I can't find a way to change the shared memory address that the green 'debug' button's functionality is determined to connect to.
The closest I've come is to add jvmoptions to the maven goal in pom.xml, and then if I add a Remote run configuration, IntelliJ lets me specify a shared memory address that matches what I wrote in the pom. This requires multiple clicks to launch the application and then debug it. It works, in a similar way that using notepad.exe to write code also works. Hence my question.
Is there a 1-step solution using shared memory?
Variation of this question:
Debugging jsp with spring-boot and IntelliJ
However the question and answers are limited to using sockets.
The problem was that IntelliJ was using the Maven goal spring-boot:run as the launch configuration, and trying to debug this causes the debugger to attach to the wrong process.
Setting a new launch configuration of type Application and pointing it at the project's class with the main() method resolves this issue.
Thanks to the commentors for suggesting that this was the way to go about it!
A one click solution (tested on IntelliJ IDEA 14.0.1) using Sockets :
Open Run/Debug Configurations, Add a new Configuration of type Remote
On the Before Lauch panel, add a Run Maven Goal with the command line command:
spring-boot:run "-Drun.jvmArguments=-Xdebug
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005"
The suspend=n option is important to avoid the Maven Goal to be locked waiting the debugger to connect.
After that you will be able to just lauch this debug task and your app will be launched and the debugger will be attached.
I have a small workspace with 3 projects. One main (Swing) application, two other projects that are just libraries.
Now, whenever I change stuff in my library project and want to execute i.e. run with Ctrl+F11) or debug , I have to select my main project first and run that.
Is there any way to set this up more smoothly, so I can just run my program regardless of which of my 3 project that is selected ?
Have a look at the "Launching" preference page. At the botton you can select *Always launch the previously launched application. That should do the trick...
If you are using Maven you can create hierarchical structure of projects, i.e. head and child projects. In this case try to define Run/Debug profile on the parent's project level. Probably it will work from any other child project.
I personally have never try this and unfortunately cannot try this right now but I hope it will work for you.
If it does not work it seem you have to create your own eclipse plugin.
Good luck.
I'm currently experiencing a problem with 'hot code replace' not working on Eclipse Galileo and JBoss 4.2.3.
Among other applications I'm running an exploded Java WAR on my local JBoss. The project from which it is build is managed by Maven. I build the project using the Maven goal war:exploded and then I copy that directory to JBoss with an ANT script.
When I'm now running the application and set a breakpoint anywhere in the code, Eclipse properly halts at that line in the debug mode.
But when I'm making a change to the source file and save it, Eclipse doesn't apply this change to the JBoss.
For example, when I make a normal code line into a comment, the debugger still steps over this comment as if it was regular Java code. Or when I remove a line, the debugger seems to get out of sync with the file and starts stepping over parenthesis.
But I'm not getting any 'hot code replace error'-messages either. It seems to me that Eclipse applies the changes to the source files, but doesn't apply it to the JBoss.
Are there any special preferences that have to be turned on in order to make hot code replace work? Or are there any mistakes in how I build and deploy the application to the JBoss?
I did not work with JBoss but I have two suggestions.
If you run your application in eclipse using the launch configuration
Is your "Project" - "Build Automatically" flag enabled?
If not, the code is not compiled and ignored t runtime.
When you debug an application in remote mode, you can not change the code, but you can change the value of parameters. (I think)
I had issues in a project with Maven and Eclipse. No errors were shown, but hot code replacement was not working. I read that "Build Automatically" has to be checked. I checked this and it still didnt work. I had some errors in other projects in my build path. I believe that was the error. When i researched, I found that the we had to uncheck the "Abort build when buildpath errors". I have given the details in the link below.
I had a similar problem with Open Liberty. Let me build on the accepted answer plus the answer from #user513365 (since a link there is now dead).
In my case I had two issues:
1. Build path errors
In my case my Incomplete build path was because I was using a Maven project with only src/main/java but without a src/test/java (so probably could have solved this by creating the latter).
But I was able to fix Hot Code Replace by going to Preferences -> Java -> Compiler -> Building and make one of two changes:
Either:
uncheck Abort build when build path errors occur OR
using the drop-down, change Incomplete build path from Error to Warning.
2. Make sure Eclipse-built classes are getting loaded
In my case my remote JVM was using a full JAR artifact from my local .m2 Maven repository. The accepted answer of enabling: "Project" - "Build Automatically" misses a subtlety here.
The Eclipse project build in my case is only going to do a hot code replace, if I do the Eclipse build after the debugger is attached. Yes, it will do the Eclipse build automatically, but if I restart my remote JVM and simply attach the debugger, it is still configured to load this class from my local .m2 JAR, and NOT pick up my local change.
FINAL NOTE ON THIS ANSWER VS. OTHER ANSWERS
If you are constantly changing the class that you are building automatically you might not notice the subtlety in point 2., and the accepted answer combined with the build path error mentioned in #user513365's answer will be all you need.
First check is the Project/Build automatically.
It may be also required to check the application server deployment configuration,
E.g. for JBoss, in Eclipse, in the Servers view, double click on the server and there is a Deployment Scanners section with two check boxes:
Add missing deployment scanners
Remove added deployment scanners before shutdown
https://docs.jboss.org/author/display/AS7/Deployment+Scanner+configuration
JBoss AS/ Deployment Scanner configuration
I just recently had this problem in Eclipse 2019-06 and found I had to uncheck the option in "Replace classfiles containing compilation errors" in Preferences->Java->Debug->Hot Code Replace group. All the other options there were checked.
Previous to doing that I was getting "Hot code replace failed - Delete method not implemented" despite my only change being to ass a System.out.println call.
As soon as I changed that option ( in the same debug session ) it started working for me.