JRebel - How to stop redeploying in Java - questions

[Raghavan Muthu]

Hello Anton,

Congratulations on the JRebel which is quite interesting and seems to be a boon.

I could see that it is an intermediate plugin to JVM.

1. Do you mind explaining the functionality of JRebel in a conceptual and design perspective?

2. I could see that it allows the users/developers to sneak peek at the changes before confirming. Is it more of a pre-deployment debug mode? Generally debugging would happen post deployment.

3. If the developer is satisfied with the changes, can JRebel allow him to push the changes to confirm further? Or the deployment has to happen separately?

4. Will it allow any dynamic changes when the code is in action with JRebel? Say a change in a property present in the configuration file?

5. How do I get access to JRebel or save its purpose?

Thanks,
Raghavan alias Saravanan M

[Anton Arhipov]

Hello & thanks!

Raghavan Muthu wrote: 1. Do you mind explaining the functionality of JRebel in a conceptual and design perspective?

JRebel implements Java agent contract in order to hook into class loading phase. When your application's class is loaded, JRebel will instrument it in order to make it capable for further reloading. JRebel also instruments some of the framework classes and builds in the required hooks that can be used later in order to reinitialize framework internals, i.e. reinitialize caches, add new components to registries, etc. Whenever a class is recompiled, the timestamp of the *class file is changed, and once the class is used by the application, JRebel will detect if the timestamp is changed. If JRebel detects that the class is changed, it will reload the class through the same class loader that was used to load the class initially and after that fire an event to all the framework plugins who might be interested in the change - then the framework internals are also reloaded.
With that said JRebel itself is a core and a number of plugins. Each plugin is dedicated to a specific framework/application server.

Raghavan Muthu wrote:
2. I could see that it allows the users/developers to sneak peek at the changes before confirming. Is it more of a pre-deployment debug mode? Generally debugging would happen post deployment.

JRebel is a development tool. It is not a debugger extension. The goal is to skip the build/redeploy phase. Imagine if you have a multi-module maven project and you deploy only a packaged version of the app. After any change you would have to execute "mvn clean package" and then deploy the artifact to the application server. You lose the time for a lengthy build, you lose time for redeploy, you lose the state of the application, you lose time to navigate to the screen whereever you've made the change and you want to tested, and also you leak memory so eventually you will have to restart the server itself. So the idea is not to debug or sneak peek, but rather cut the time wasted.

Raghavan Muthu wrote:
3. If the developer is satisfied with the changes, can JRebel allow him to push the changes to confirm further? Or the deployment has to happen separately?

Related to the question nr. 2. There's no preview available - what is done is there instantly, in your application. The preview mode is available however in a tool called LiveRebel, but that is aimed rather for operations, not developers.

Raghavan Muthu wrote:
4. Will it allow any dynamic changes when the code is in action with JRebel? Say a change in a property present in the configuration file?

Yes, and no. You have to understand that Java code is not the same as configuration files. Java code changes are supported by the core functionality of JRebel, but configuration changes require special integration. For instance, if you have Spring framework XML file, and you want to add a new bean definition - this is something that should be specially handled. There's a list of frameworks that we currently integrate with and the number of supported frameworks is constantly growing.

Raghavan Muthu wrote:
5. How do I get access to JRebel or save its purpose?

Could you explain the last question. I'm not quite sure if I understood it right.
To download JRebel prodceed to download page.

[Amit Nimbhorkar]

Hello Anton,

Do we have something for the problem where developers have to .ear OR .war files on the server to test there development? Rather, they should be able to test there code on server while development itself. Does JRebel provide any such feature?

Amit

[Anton Arhipov]

Amit Nimbhorkar wrote:Do we have something for the problem where developers have to .ear OR .war files on the server to test there development?

It is possible to map the deployed archive back to your active workspace using the special configuration file. So if you absolutely need to deploy EAR or WAR, you can do that once, including rebel.xml to the archive and be mapping the correct directories, and then you should be able to see the changes propagated to the application.

[Damian Cardozo]

Hi Anton,

I have an on going JSF+EJB+JPA project (using netbeans). How much work is required to integrate JRebel? and suppose that I buy a license, but when it expires I don't have enough money to buy it again.. how much work is required to remove JRebel from the project?

Thanks,
Damian

[Anton Arhipov]

Damian Cardozo wrote:I have an on going JSF+EJB+JPA project (using netbeans). How much work is required to integrate JRebel?

Setting up JRebel requires 2 general steps:
1) add -javaagent VM property to to application server startup script (e.g. java -javaagent:/path/to/jrebel.jar)
2) Mapping the deployed application back to the active workspace with rebel.xml

To automate the setup even more, an IDE plugin could be used. However the NetBeans plugin is not as sophisticated yet as for Eclipse and IntelliJ, you can still live without the fancy automation features. The NetBeans plugin is still in works right now.

Damian Cardozo wrote:and suppose that I buy a license, but when it expires I don't have enough money to buy it again.. how much work is required to remove JRebel from the project?

Just remove the Java agent VM argument, and delete rebel.xml from your project. If the license expires, even if you still have JRebel agent configured, it will do nothing so it's not harmful.

[Nenad Nikolic]

Hallo Anton,

Is it possible to add custom JRebel-aware behaviour in my app allowing me implement custom functionality when classes inside of the JVM are updated by JRebel? One usage of such hooks would be telling some external server/service to reinitialize/restart whenever the developed application is being modified (and updated in the JVM).

JRebel plugins are mentioned in the JRebel FAQ and that might be the answer, but that page currently shows a sad 404 dog.

Cheers!
Shonzilla

[Anton Arhipov]

Hello, Nenad!

Nenad Nikolic wrote: Is it possible to add custom JRebel-aware behaviour in my app allowing me implement custom functionality when classes inside of the JVM are updated by JRebel? One usage of such hooks would be telling some external server/service to reinitialize/restart whenever the developed application is being modified (and updated in the JVM).

Yes, that is how the current integrations with the frameworks are implemented in JRebel. You can read about the API here. The description is quite basic but I think you'll get the idea. More tutorials about the SDK/API will come online soon.

Nenad Nikolic wrote: JRebel plugins are mentioned in the JRebel FAQ and that might be the answer, but that page currently shows a sad 404 dog.

The link is fixed now, sorry about that.

[Raghavan Muthu]

Hello Anton,

Thanks for the detailed reply. Sorry for coming a bit late.

I guess there were many other questions being asked in the thread

My last question was how do I actually make use of JRebel? Is there any console or a screen with which I can really see what I am doing? As you said, you can have a quick look at the changes before deploying (ideally, stop redeploying).

[Anton Arhipov]

Hi,

Raghavan Muthu wrote: My last question was how do I actually make use of JRebel? Is there any console or a screen with which I can really see what I am doing? As you said, you can have a quick look at the changes before deploying (ideally, stop redeploying).

You basically need 2 things - configure the -javaagent VM argument pointing to jrebel.jar, and including rebel.xml configuration file to your deployed package.
These isn't anything like a console right now that would tell you that the change is capable for reloading or not. However you will get a notification about class hierarchy change if you try to change class relations - but this is only post-factum, you will need to restart/redeploy after that anyway.

Essentially - you make a change, you recompile the code (or just save if using Eclipse), switch back to your application - and hit F5, that simple

[Raghavan Muthu]

Thank you. It was what I wanted

Thanks for all the clarifications. It is quite interesting

Congratulations to you once again and best wishes for your endeavours

[Raymond Holguin]

whats types of coding changes (if any) will NOT be caught by JRebel and require a full redeploy?

[Anton Arhipov]

Raymond Holguin wrote:whats types of coding changes (if any) will NOT be caught by JRebel and require a full redeploy?

- Hierarchy changes, i.e. replacing superclass
- Adding/removing implemented interfaces

Also, since the initializers are not re-executed, it means the state is preserved, but if you add some initialization logic - then it is only applied to the new class instances. For instance, you add a field and initialize it in constructor, then the old instances will have the new field but the value will be null.

[Raymond Holguin]

Anton Arhipov wrote:

Raymond Holguin wrote:whats types of coding changes (if any) will NOT be caught by JRebel and require a full redeploy?

- Hierarchy changes, i.e. replacing superclass
- Adding/removing implemented interfaces

Also, since the initializers are not re-executed, it means the state is preserved, but if you add some initialization logic - then it is only applied to the new class instances. For instance, you add a field and initialize it in constructor, then the old instances will have the new field but the value will be null.

Are these limitations of JRebel and will addressed in future releases or are these issues out of your control?

[Anton Arhipov]

The missing features are on the roadmap.

[Vic Hood]

Hi Anton ,
Welcome to the ranch! I'm a newbie to Java In General , but this redeploying thing often gets to the nerve of a developer , as every minor change in a class file merits a redeployment . Will the use of JRebel circumvent that?
Also why does it needs to be redeployed each time?
I have seen that at times it works well without redeployment and sometimes where the IDE(Eclipse) throws a set of foul mouthed exceptions. It would be great if you could touch upon why this happens.
Thanks

[Sujoy Choudhury]

Hi Vic,
You can read the whole post to get the idea.

Definitely you can do it using Eclipse Hot Deploy but there are many limitations which JRebel has solutions to those.
You can read it here too
https://coderanch.com/t/554053/vc/Eclipse-Hot-Deploy-JRebel

[Anton Arhipov]

Vic,

JRebel is exactly aimed for the problem you've described - its goal is to eliminate redeploys.

If you are interested in learning more about the problem of redeloys you may find very useful blog posts at our website. There's a very interesting series of Reloading Java Classes post which I'd suggest to take a look at.

[Santosh U Prabhu]

Hi Anton,

I guess this is the right thread to post. Is JRebel connected to OSGI framework? I am analyzing the OSGI framework for hot and continuous deploys and I see that OSGI has some learning curve.

[shareef hiasat]

thank you

[Anton Arhipov]

Santosh,

JRebel integrates with OSGi infrastructure to enable class reloading within the OSGi environment. Technically it is *not* related to OSGi as an implementation.