For some reason, Eclipse is giving me ##$%.
First, some Basic info:
Currently I'm using Eclipse Kepler, on a Mac with OS 10.8.4, 4CPUs and 16GB RAM.
Additionally, I'm using the Spring 3.1.0-Release version.
All I'm doing is running an Integration Test using the SpringJUnit4ClassRunner class, this is a test to see the application context can be loaded:
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration(locations = { TestConfiguration.TestApplicationContextFile })
public class InitIT {
#Test
public void testInit() {
}
}
What happens when the application context has a problem (for instance, someone forgot to put a #Component annotation on a class and we get a "BeanCreationException"), eclipse simply freezes and refuses to do anything.
I can't even see the stacktrace, so I can't see what the problem is, and Eclipse just uses 100%+ of CPU and hangs, not even letting me press "Stop".
This doesn't happen every time, but when it does it's very consistent.
Also, needless to say, when the application context is loaded successfully, everything runs smoothly, so it's only a matter of when there's a problem.
Something I've discovered that may give a clue is that when I simply load the application context from a Main function instead of using SpringJUnit4ClassRunner, then it's a bit better, but it still takes Eclipse a few minutes to "cool down" and be nice enough to show me the stack trace.
Any ideas? Please let me know if I could send any more info that could help
:)
Thanks!
Ido
Related
When running my code in debug mode, I keep getting 2 error messages:
Could not delete [path_to]\productiondb.log. May be locked by another process
I don't know what process might be locking it. It comes when I make changes to the code while my Pivotal tc Server is running in debug mode, but it dosent seem to create a lot's of trouble. Sometimes however, I get this warning:
Also due to some changes. I usally just restart the server and move on. This isen't the real problem, the real problem is that I get these messages when I havent doen any changes. Somethimes it accures when I run a certen part of the code, other times i occurs when I open certen codes in sts, however, it doen't seem to stop at the same place twice.
I am suspecting that this has something to do with git. I am using git to change between versions and doing tests. So I am thinking that STS has some of the code in memory from before I changed branche with git, and isen't updating it before I run or open the file with that code. But I am rather new to both sts and git, and can't be certan that it would work that way. If it is, does anyone know how to update sts after I have changed branch? If it is not, does anyone know what might causing it?
If you run an app in debug mode, the Eclipse Debugger tells the application when code gets changed and tries to use the debug API to swap in the new code into the running application. This is especially useful if you debug your code, hit a breakpoint, step through the code, fit the issue, change the code, and press save. At that moment, the Eclipse compiler updates the class file and tells the running JVM to swap in the new code. If that succeeds, the debugger will jump back to the last stack frame and the execution of your app will continue with the beginning of the method that you entered. This allows you to directly continue to debug and step through the updated code without restarting the app.
While this is a great feature of the JVM, it is very limited in terms of what scope of changes to the classes the JVM can deal with while doing this hot-swap. It is usually limited to method implementations. So adding new methods, adding or deleting members of the class, etc, are not supported. As a result, the above screenshot will appear. It means that the JVM wasn't able to hot-swap the changed code and will continue to run with the previously loaded code instead of the changed one.
I'm trying to fix a problem in an Eclipse plugin at https://github.com/davidmichaelkarr/e4macs . The repo is a fork of the original application, which is now abandonware.
I have a couple problems with this, but I'm going to limit the scope of the question, hopefully making it simpler for someone to provide an answer.
The main problem I'm having with the plugin is that some operations (the operation "split-window-vertically" in particular) simply do nothing when I execute them. This didn't used to be the case. In some recent versions of Eclipse, this was working fine. It stopped working about 2019-09.
What I want to do first is add log statements that show it's at least getting to the handler method. I've concluded that I don't know how to add logging to an Eclipse plugin. The existing code for the plugin doesn't do any logging, so I don't have an example to go by. I've searched the net for documentation on how to do this, but all the articles I've found are either incomplete or just don't work.
I know of at least one handler that IS working properly. I added what I thought was the correct logging code to that handler, and it never appeared in the ".metadata/.log" file, so I assume that that was not the correct way to do logging.
I saw a reference to using "Activator.getDefault()", but that posting didn't say what the FQCN is, and all the completion offerings I found didn't have a "getDefault()" method.
Update:
I added something like the following to two classes:
private ILog logger = Platform.getLog(<ContainingClass>.class);
And then in a method in each of these classes, I used logger.info("message");
I ran this in my debug instance and tested the operations in both classes. The log messages appeared.
I then uninstalled the plugin from the main installation, then built the plugin in my RPC instance, then reinstalled the plugin in the main installation, from the local update site defined by the "...Update" project.
I then tested both operations, and I saw nothing in the log.
I may have solved my logging problem at this point, but I'm still having some sort of problem with deployment. I have a feeling that the process I went through to reinstall the changed plugin is not working.
To get an activator with a getDefault() method you must specify that the plugin contributes to the UI when you create it and that you want an Activator to be created. This should create an activator class extending AbstractUIPlugin and with a getDefault() static method.
In any plugin you can always use:
IStatus status = new Status(....);
ILog log = Platform.getLog(getClass());
log.log(status);
to log a status object.
Status has numerous constructors. A simple one just to log a message is:
new Status(IStatus.INFO, "plugin id", "message");
Platform is org.eclipse.core.runtime.Platform
Status is org.eclipse.core.runtime.Status
everytime I try to step into a class during eclipse debugging sessions I get a whole call stack of a ClassNotFoundException which the JVM throws during class loading. This means the call propagates through the AppClassLoader, ExtClassLoader and URLClassLoader which finally throws the exception. I can now step out this entire tree and just do a step-in again and then it'll work but I don't need to tell you that this is annoying like hell.
Does anyone have an idea what's wrong with my config? Interestingly enough I tried this on two fresh eclipse installations but it still happens. I thought about an exception breakpoint but there is none...
While trying to use GWT Super Dev Mode, I followed those guidelines :
GWT-2.5-Super-Dev-Mode
Introducing Super Dev Mode
How does GWT's Super Dev Mode work?
However, I am stuck at the step trying to turn on Super Dev Mode :
Once I fully compiled my project, I run the code server and the dev mode, go at http://127.0.0.1:8888/myapp.html (without the ?gwt.codesvr=127.0.0.1:9997) and then click on the bookmark Dev Mode On. It detects my module, asks me to recompile, a glass screen appears with a message Compiling MyApp ... and then nothing ... No error, no stack trace either in Chrome or Eclipse. Just nothing happens.
Debugging the js code from dev_mode_on.js file, the script is interrupted at line 324 :
...
function getBindingParameters(module_name, get_prop_map) {
var session_key = '__gwtDevModeSession:' + module_name;
--> var prop_map = get_prop_map(); <--
...
Once the function get_prop_map is called, a few more obfuscated functions run and the debugger returns.
I know it is still experimental, but do you have any idea of what I could have done wrong ?
PS: I am using GWT 2.5, GWT-maven-plugin 2.5 and Chrome 23.0.1271.64 m
We have found a similar issue and tracked down the cause, looks like a boundary case not handled in GWT.
More info can be found here: http://code.google.com/p/google-web-toolkit/issues/detail?id=7894
I don't have an answer, but I can give some general debugging tips for this sort of problem.
Super Dev Mode currently (as of 2.5) doesn't report any progress to the web browser while it's compiling. It won't update the dialog until the compile finishes. So it's possible that it's just very slow for your program for some reason, or the compile stopped and somehow didn't report an error like it normally does.
However, there are other ways you can monitor its progress. The compiler log is available as a web page by following links from the code server's front page; you will have to refresh the page to see updates. Or you could look at the log on disk in the code server's work directory. (You can set the work directory with the -workDir argument when you start it.)
Another way is to start the code server from the command line. Any stack traces from the code server will be printed there. You should also be able to look at the output in Eclipse or IntelliJ if you're running it from there.
From this you should be able to tell whether the compiler is slow, but still working (it's still printing output) or has actually stopped with a stack trace.
I am using Eclipse IDE (Helios Version)
While debugging in Eclipse , is it possible to edit the source and continue debugging ??
For example i have this file
While debugging when i tried to modify the a4 value during debugging its not reflecting ??
public class Tes {
public static void main(String args[]) {
int a4 = 15;
for (int i = 0; i < a4; i++) {
System.out.println(i);
}
}
}
Yes it is possible to edit the source and continue debugging in Eclipse! You'll find extensive information here: Debugging with the Eclipse Platform (scroll down to the section Hotswap Bug Fixing: On-the-fly code fixing).
If you are running Java Virtual Machine (JVM) V1.4 or higher, Eclipse
supports a feature called Hotswap Bug Fixing (not available in JVM
V1.3 or lower). It allows the changing of source code during a
debugger session, which is better than exiting the application,
changing the code, recompiling, then starting another debugging
session. To use this function, simply change the code in the editor
and resume debugging.
There are some cases where the feature will not work. E.g. if you make changes to your main method's a4 variable, the JVM will not be able to remove all stack frames running old code from the call stack. The debugger data will be lost.
To see the Hotswap Bug Fixing JVM feature in action, just move the code from your main method in the Test class to some other class. Here's what I mean:
Now you can modify the code on the fly while debugging in the MyObject class. Have fun!
EDIT: Just found a similar question at superuser.com: Debugging in Eclipse, how to run until a breakpoint
If you happen to be running your application using a 1.3 JVM or higher versions, there's one final step with the debugger still running:
-> change the problem line - in your case "a4 value" and then Save the file, then press the Resume button to get the application running again.
This Saving of that particular java file that you have edited during debugging, will make the session to continue debugging from start(Constructor) of the file with new values.
This editing and saving can be done n number of times, and once you save it, the debugging session will automatically resume from the start of that particular file.
If you just want to change the value of a5 during debugging its alot easier than changing the source.
You can set a new value in the variables view you can see when in the debugging perspective in Eclipse.
See the manual here and here