This chapter documents common JRebel problems and provides ways to resolve them.
Before you continue, enable logging. The JRebel log files help you and JRebel Support to troubleshoot issues. Make sure you have enabled logging by adding
-Drebel.log=true to the startup parameters – or confirm the logging settings in your JRebel IDE plugin settings via Help > JRebel > Configuration. The default location of the log file is in the
Whenever JRebel Support asks you for the log files, refer to sending logs for more information.
Server or application fails to start¶
You completed the JRebel setup successfully, but for some reason your server or application does not start. Here is what you can do.
JRebel agent is not found¶
Problem: This message is shown in the log:
Error opening zip file: /jrebel/jrebel.jar ... Error occurred during initialization of VM agent library failed to init: instrument
Solution: The path leading to
-agentpath is incorrect. Confirm the exact location of JRebel and specify that path with
-agentpath:[path/to]jrebel. For more information, please refer to running server from command line.
JRebel fails to start with Java 1.4 or IBM JDK¶
Problem: JRebel fails to start when using Java 1.4 or IBM JDK.
Solution: Make sure that you generate
jrebel-bootstrap.jar with the exact same JVM version and JRebel version that the server is started with. To generate
java -jar jrebel.jar. Make sure that the
java -version is correct.
JRebel runs out of memory¶
Problem: JRebel fails to start due to a
Solution: Try adding more memory to the heap. When permgen space is mentioned, add
-XX:MaxPermSize=128M (increase the number where necessary) to the JVM command line parameters. Otherwise, add
-Xmx256m or increase this number if already present. Keep in mind that running out of memory or permgen space can cause the JVM to crash altogether.
JRebel fails to start¶
The following console banner is always shown when JRebel starts successfully:
2016-08-08 13:48:25 JRebel: ##################################################### 2016-08-08 13:48:25 JRebel: 2016-08-08 13:48:25 JRebel: JRebel Legacy Agent 6.4.7 (201607271052) 2016-08-08 13:48:25 JRebel: (c) Copyright ZeroTurnaround AS, Estonia, Tartu. 2016-08-08 13:48:25 JRebel: 2016-08-08 13:48:25 JRebel: Over the last 1 days JRebel prevented 2016-08-08 13:48:25 JRebel: at least 1 redeploys/restarts saving you 2016-08-08 13:48:25 JRebel: about 0 hours. 2016-08-08 13:48:25 JRebel: 2016-08-08 13:48:25 JRebel: #####################################################
If this does not show up, here are the things to check.
Confirm JRebel is present in startup parameters¶
-javaagent:jrebel.jar gets to the JVM command line. When you changed
%JAVA_OPTIONS% to include it, try adding
echo %JAVA_OPTS% to the server startup script.
Make sure you are looking at the right console¶
With some application servers (e.g. WebSphere and GlassFish), it is possible that the banner is shown, but hidden in one of the console output logs. Check those logs to find it. Or check
jrebel.log to confirm JRebel launch.
JRebel evaluation license has expired¶
Seeing this message means that the 14-day JRebel evaluation is over. However, sometimes this is shown even when you have a valid license. In that case:
- Check that
jrebel.licis present in your
- To verify
jrebel.logfor “License information”. The
limitedUntilfield defines when the license is going to expire.
Classes or resources are not reloaded¶
These are the possible problems and solutions when JRebel is set up and started correctly (JRebel startup banner visible in the console), but the classes do not get reloaded:
Keep this in mind: when you are testing JRebel and think that classes are not being reloaded, be absolutely sure. Note that JRebel only issues a console statement when a previous version of the class has already been loaded. Just changing some class does not cause it to be reloaded – unless you accessed it before.
- Are the classes monitored? The first thing to check is that JRebel actually monitors the directories with compiled classes in your workspace. To do this, search
jrebel.logfor “monitored for changes”. If you do not find any, then probably
rebel.xmlhas not been generated, or it is not present or recognized in the application archive. If the monitored folders are present, you know exactly where JRebel is expecting to find updated classes and resources. Check these accordingly. Refer to rebel.xml configuration in the reference manual for more information.
- If you cannot find any monitored folders, it could mean that your
rebel.xmlis not present in the application archive or that it is incorrect. To find out, search for “rebel.xml” in
jrebel.log. It will show you both where the
rebel.xmlis found from and its content. You can search
jrebel.logfor “does not exist” to make sure that all folders mentioned in
rebel.xmlactually do exist.
- Once you are convinced that JRebel is monitoring these folders, it should pick up changes to the resources. However, to make sure that changes to classes are picked up, search
jrebel.logfor the term “instrumented”. JRebel issues a log statement with this word for each class it loaded and will be monitoring for changes. If such a statement is missing, that class probably has not been loaded. In this case, make sure your deployed application reflects the source code.
- Do the classes get recompiled? If you checked that both the folders and classes are monitored, be sure to check that the classes are being compiled. Does your IDE support the auto-compile on save feature? If not, make sure to compile the changed classes manually. Find the “instrumented” class statement in
jrebel.logfor the class you will be updating. This also tells you exactly what .class file it is reloaded from. Find that .class file and monitor its timestamp (last modified time), while updating it from the IDE. If the timestamp does not change, you should check your compilation settings in the IDE. Also make sure that the monitored folder is the same as the IDE output folder.
- Does the reloaded code get re-executed? Keep in mind that some parts of your application code are executed just once. When you are changing a constructor or initializer method on an already created object, chances are that it will not be run again. Even if JRebel does reload the class, this will not reflect in the application until that component is recreated.
JRebel debugger fails¶
Make sure your JRebel IDE plugin is installed correctly.
I checked everything and it still does not work!¶
Try searching the forum. You also have a direct line to the development team via the IDE plugins – open Help > JRebel > Submit a Support Ticket.
You can also email us or post to the forums. Let us know and we will be glad to help you with your issues. A good idea is to include a zipped
jrebel.log when writing to support (refer to sending logs for help), because this will be the first thing we ask you for anyway :)
Try to be as specific as you can with the information about your environment: Java version, application server (and version), what are the frameworks that are used in your application, etc. This information will greatly speed up the investigation.