Help coderanch get a
new server
by contributing to the fundraiser

Anton Arhipov

JRebel Software Support
+ Follow
since Aug 05, 2011
Anton likes ...
IntelliJ IDE VI Editor Java
Merit badge: grant badges
Software Engineer and JRebel Product Lead at ZeroTurnaround. IntelliJ and Vim fan, Java addict.
For More
Tallinn, Estonia
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Anton Arhipov

Nick Widelec wrote:

jrebel.jar is exactly there, however still does not work and I get the error message:

Error opening zip file or JAR manifest missing :

I am using jdk6 and jboss 4.2.3. Thanks in advance.

You have a whitespace after colon in -javaagent: argument.

-javaagent: c:/jrebel/jrebel.jar should actually be -javaagent:c:/jrebel/jrebel.jar
10 years ago
Thanks for asking the questions!

Please feel free to ask more at our forums!

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

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.

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.

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

Sujoy Choudhury wrote:JRebel prevents memory leaking, so does that mean JRebel instance can be used for endless retries without restarting?

Ideally, yes. JRebel still adds some memory overhead but since you're likely to update only small changes, the memory consumption will not grow as fast as when you redeploy. Ideally you should be able to start your application server in the morning and shut it down in the evening without having to restart during the day - that's a goal.
We have been researching if Clojure needs JRebel support at all since most of the development there is done by composing functions in REPL. And for that case JRebel didn't seem to be required. But there was a case, when a class is compiled using class-gen macro - then the special integration with JRebel was required.

Groovy is supported in JRebel officially.

Most likely, in the upcoming releases, we will add support for JRuby also. Actually JRebel is already capable and works with JRuby but it just needs some polishing.
Well, there is a free version of Java devs also - it is called JRebel Social but its EULA restricts the commercial use.
Scala has all the same problems as Java in regards to class reloading.

The difference is that for Scala developers JRebel is FREE If you're interested in getting the license for Scala - you can apply here and you will receive the license automatically.
Thanks for the hearty welcome everyone! Hope you will have lots of questions about JRebel

Erron Austin wrote:1. Have you had any clients using the your product with Liferay?

Yes, we have users, especially some large consultancies reported using JRebel with Liferay. Nail Griffin himself was quite enthusiastic about it.

Erron Austin wrote:2. Do you think using JRebel would be more reliable than the method of just copying over the updated JSP?

It depends on the application server, I think. What JRebel does in case of JSPs - in the simplest case it just redirects the JSP resource lookup from the container to the workspace where you've made the changes and delegates the re-compilation of the JSP to the container itself. However, if you're using JSP scriplets - it requires some special support in order for a scriplet to see regular class changes which is not solved by just copying the JSP file to the desired location.
So in that case JRebel definitely adds value when working with JSP.

Erron Austin wrote:3. Do JRebel having any issues with static classes/methods?

Static classes & methods are supported.

Paul Wallace wrote:How well does JRebel play with IBM RAD and WAS?

JRebel Eclipse plugin is suitable for installing into RAD. JRebel itself supports WAS quite well. I suggest you take a look at step-by-step tutorial on how to get started with RAD/WAS and JRebel. There's also a recording available of a dedicated webinar session.

Paul Wallace wrote:Are the class files instrumented in any way when JRebel is part of your dev setup?

Yes, to make the classes capable for reloading, JRebel instruments the classes with the required pieces of code. Also, the plugins for frameworks generate special hooks into the frameworks in order to trigger re-initialization when needed.
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.