IntelliJ IDEA by default has the functionality to debug/run more than one instance of the same program.
For example; if I run debug on Project X and it's main threads is in waiting, sometimes I come back and run it again as the DEBUG button is not indicating a currently executing session. Nor does IntelliJ stop you from running another session of the same program (Project X)
Why is this functionality necessary, and how can I turn it off?
a) The functionality is very good when you want to rerun a configuration in a new instance.
For example a simple client that you want to start in several instances without any other effort.
b) You cannot really turn it off.
This will start a new Run or Debug session:
This will rerun the current Debug session:
This will show you your current Debug sessions:
You can enable the Single instance only option. To do this,
Go to Edit Configurations... in the dropdown to the left of the Run button.
Select the appropriate configuration.
Click the Single instance only checkbox.
Related
I'm using IntelliJ to run my app. Is there a way to relaunch the window or close the current one when hitting the run button?
This is because when I hit the run button it creates a new window every time. It gets a bit tedious/confusing to close the previous window that is running old code.
Go to the Run menu and select Edit configurations...
Select the configuration you've been using to run your project in the left panel. Either it's the Gradle yourProjectName:desktop [run] task, or it's an Application run configuration you've created yourself.
Uncheck the box that says "Allow parallel run".
The next time you try to run it when it's already running, it will warn you that it can only run it if it kills the old process. You can check a box in this dialog to do that automatically from now on.
I've never figured a way to toggle this behavior back to how it was, but I've rarely ever needed to compare two builds side-by-side.
I'm debugging a multi process java application. I start the first process with a breakpoint set after it starts the child process. The child process then goes into a loop waiting to be manually broken in the debugger so that I have time to attach to it.
I'd like to have the breakpoint in the parent process trigger the NetBeans debugger to go and attach to the child process (which is started with a debug listener port).
This would make debugging the child much easier.
The only current actions I see are Enable and Disable groups of other breakpoints....
I ended up writing a Netbeans module that interacts with supporting code in my application to catch child process creation and then automatically attaches to them on a debug port they're using.
It does this through an automatically created hidden breakpoint (on a method my application calls when a child is spawned). That breakpoint evaluates a static method in the support class in my application to get the debug port. It then tries to attach to that port and resumes the application from the breakpoint.
The end effect is that I get automatic attachment to a child process with no user intervention. Just Start-Debug on the main application and then breakpoints get hit seamlessly in the child processes. Like the gdb option (set follow-fork-mode child) to attach and follow children processes after a fork/exec.
It only works in my specific case as I control both the Netbeans plugin module and the application under development.
I can't post the whole source here, but the things I used to achieve this included:
DebuggerManager.getDebuggerManager().addDebuggerListener();
MethodBreakpoint.create();
RequestProcessor.getDefault().post();
DebuggerInfo.create ("netbeans-jpda-AttachingDICookie", new Object [] {AttachingDICookie.create ("localhost",port)} );
DebuggerManager.getDebuggerManager().startDebugging()
JPDADebugger d = DebuggerEngine.lookupFirst("", JPDADebugger.class);
JPDADebugger.waitRunning();
The magic string "netbeans-jpda-AttachingDICookie" was the hardest thing to figure out in this. It took debugging the netbeans debugger through a normal attach process call to find this value. I have not been able to find it documented anywhere.
I wish the run command (usually default to CTRL+F11 combination) of a Java project (and C++ if you know it too) to automatically close the previous process (or all processes, if it's easier) started by it before it runs a new instance.
In short, running a project should also close previous app instance. Is it possible?
Maybe it's possible to add code to the app itself, and disable it once I don't need it anymore? I want it since it's annoying to close the app each time. I don't need so many instances of the app.
In Eclipse Neon go to Window -> Preferences -> Run/Debug -> Launching and in the Launch Operation section check:
[X] Terminate and Relaunch while launching
Easier said than done. I suggest you terminate the process yourself by clicking on the little red stop icon in the console or by terminating the main thread from the threads view in the debugger perspective.
That's not possible with Eclipse built-in features. The easiest way to automate this seems to be
Install the launch group feature from CDT (you only need the mentioned feature) or the EclipseRunner plugin. They allow creation of "batch" launch configurations.
Create an external run configuration with a "kill" command (depending on your operating system), which can kill your application process based on the application name.
Create a batch launch group with one of the two plugins mentioned above, where the "kill" configuration comes first and your normal launch configuration comes second.
I'm developing a standalone server (not a war) using Eclipse Juno. I run it as a Java application from Eclipse. After I've made some code changes, I want to stop the currently running server and start it up again. I do this tens of times a day.
The way I do that at the moment is as follows:
- Go to the "Debug" tab.
- Select the server process.
- Click on the stop process icon (red square).
- Click on the green arrow to re-run the last run application.
- Go back to the "Java" tab.
Is there a quicker way?
Ideally, I'd like a button or keyboard shortcut that would stop and restart the application in one click. If it doesn't already exist, can I extend Eclipse in some way? Where should I look for an example of something like this?
You can restart running application by right clicking it in debug window and selecting "Terminate and relaunch".
And quickly switching beetween views with Ctrl+F8
Also if you've already terminated the application from console, you can simply hit ctrl + f11
If you really want you can also add custom shortcut for terminating and relaunching by Window -> Preferences -> General -> Keys -> Find "Terminate and Relaunch" and choose your favorite key combination!
Eclipse Neon.1 added a way to terminate before relaunch by holding Shift while clicking on a launch history item.
You can also make that the default behaviour by enabling the option “Terminate and Relaunch while launching” in Preferences › Run/Debug › Launching.
https://www.eclipse.org/eclipse/news/4.6/platform.php#terminate-relaunch-history
I had the exact problem you had. I had a simple Java class with a main method that runs an embedded tomcat.
When I change any of my service classes, I wanted to terminate the current embedded tomcat and relaunch with one single keystroke.
I know, I could have just clicked and done the same with 2 mouse clicks... but... it pained me enough to learn a wee wee bit about Eclipse plugin and threw something together.
Hope this helps you too.
https://bitbucket.org/mantis78/relaunch-plugin/wiki/Home
Simply saying, You can't modify eclipse Like you wants to. But You can follow this procedure to minimize your effort
1. In Eclipse Project TAb-> Check Build Automatically.
2. And After Every Changes You are making Just Run The Project using Green button in eclipse.
Also you Can use CTRL+F11 to run project.
My problem is somewhat like the question here and here, but none of those answer can apply to my situation.
I am running tomcat inside Eclipse, and my project has some quartz job that run by schedule. Those quartz job meets null pointer exception very often (since they must parse documents from an untrusted source) and surely the team who are working with those jobs can't fix them right away.
The result is that Eclipse pop up debug tab every now and then, usually take up focus so that I can't look what happen in console. Moreover, when Eclipse meet the exception, it pop out to take focus out of the program I currently work in (browser, email,...). It is very annoying.
Can I simply skip all the null pointer exceptions (since the fail of the jobs doesn't affect my program anyway) or is there a way to keep the focus on the console tab, and keep Eclipse doesn't complain everytime an exception pop out?
I'm very thankful for any possible solution.
UPDATE: I'm using Eclipse Helios with few plugins.
Have you looked in Eclipse's settings under Run/Debug? There are two useful options you can change;
Activate the workbench when a breakpoint is hit
Activate the debug view when a breakpoint is hit
Another obvious option would be to not use debug mode and "run" the application instead (AFAIK, breakpoints will never stop execution when "Running" code instead of "Debugging" it).
Window > Preferences > Run/Debug > Perspectives >
> Open the associated perspective when an application suspsends:
Set to Never, or Prompt (as desired)
It sounds like you have an unwanted Breakpoint set up in your Workspace. Open up your Breakpoints view, and you should see a breakpoint listed as a NullPointerException, RuntimeException or Exception. Uncheck it.
If you want to suspend the thread for all other occurences of NullPointerException, then you could look into Conditional Breakpoints (i.e. right-click on the breakpoint in the BreakPoints view, and click on Properties. You'll see a dialog with options for 'Conditional breakpoints'). That should set you on your way.
Edit: here's another possibility. Try looking in the Java Debug preferences:
Menu > Window > Preferences
Then choose:
Java > Debug
Now uncheck an option called:
Suspend execution on uncaught exceptions