Category: Java

Posted on

JRebel 5.0 – 5.1

I was on the verge of doing a new write up but due to work I couldn’t get very far. I had compiled some text into a file and here it is:

In JRebel 5.0 I noticed some stuff.

It seems that JPA NamedQueries are not changed on reload. It is not certain that this is supported, about that unsure I am.
Spring 3.1 MVC Controllers are not reloaded (Luckily there is always the nightly build of JRebel and it fixed that when I was using 5.0!)
Another thing I noticed is that Spring Reloadable Message bundle new properties are not reloaded
And then the good stuff! better IDE integration, easier single click activation of JRebel for multiple projects thanks to the JRebel Config Center making a developers life much much more comfortable. Almost all latest Java Frameworks are supported!

JRebel 5.1

At work I’m making an app called ECW it’s not that big, only 11k lines of code. But I got some stats, and remarks by that statistics.

Tomcat Startup times:
ECW no JRebel = INFO: Server startup in 6255 ms
ECW with JRebel = INFO: Server startup in 13420 ms

Of course the doubled startup time is is neglectable! Why? You almost don’t have to restart tomcat the whole day!

an issue I had an fixed was:
Java 7 and Java 6 mixed … Not working. By default JRebel seems to be using Java Version of eclipse, instead of the version used for project/compilation/running tomcat, setting JAVA_HOME to java6 and still using -vm jdk7 to run eclipse , fixed the issue. This is probably documented in the documentation but I didn’t see it come up in the google search 🙂

And then some more stats:

JRebel 5.1.0 (201210161346)
[2012-11-27 21:57:38] (c) Copyright ZeroTurnaround OU, Estonia, Tartu.
[2012-11-27 21:57:38]
[2012-11-27 21:57:38] Over the last 30 days JRebel prevented
[2012-11-27 21:57:38] at least 193 redeploys/restarts saving you about 2.4 hours.
[2012-11-27 21:57:38]
[2012-11-27 21:57:38] Over the last 84 days JRebel prevented
[2012-11-27 21:57:38] at least 577 redeploys/restarts saving you about 7.1 hours.

Stats are always fun! What can ZeroTurnaround do to make them more fun?
Add a total time a server was running with JRebel. And perhaps the total deploys that happened during that time. Instead of just notifying the time saved. In the case of the above stats 2.4 hours seems very little, and 7.1 hours over 84 days, maybe even less. IMHO the stats would say much more if the total manual deploys are visible too.
Something like:
[2012-11-27 21:57:38] Over the last 84 days JRebel prevented
[2012-11-27 21:57:38] at least 577 redeploys/restarts saving you about 7.1 hours.
You had 168 (taking about 3.7 hours) manual deployments over a total running time of 240h.

You can do the math yourself from the above stats. Suppose that I had to manually deploy those 577 everytime. I would have lost 1 day in 240h ( 30days).

Points where JRebel could improve. If technically possible.

Deploy new classes, and a whole class tree (e.g. when a superclass changed), add new properties that are added in properties files. (Disclaimer: perhaps JRebel can do all that and is illconfigured at my side)

What did I conclude from using JRebel the last 3 months?

  • the bigger the app the more useful it gets!
  • if I disable it for a day I have to go to a rehab center
  • stats can be more irie
  • I love zeroturnaround, but it’s to far from home to even consider sending them my resumé

Note: Now that they made LiveRebel free for 2 servers it is time to try it! (and buy it for all your servers)

 

Disclaimer: I do not work for ZeroTurnaround, neither am I affiliated to them in any way!

Posted on

Logback-webfragment in repo

Logback-webfragment (Java7 version) is now available in Maven Central.

The following dependency declaration in your pom will get it for you.

<dependency>
    <groupId>be.redlab.logback</groupId>
    <artifactId>aaa-logback-webfragment</artifactId>
    <version>1.0.1</version>
</dependency>

View the details in nexus, view the maven site

Upon request, I can upload the Java 6 version too.

Posted on

Logback and webapplications

Lately I prefer to use Logback for logging purposes. Logback natively supports slf4j, a log abstraction api through other logging frameworks all can log to a logging framework of your choice.
When using logback in webapplication and you want your logging configuration file outside of your app you can set a systemproperty to point to the location.
However if you want it configured like you are used to do with Spring, log4j and the log4j servletcontext listener, you have to write the context listener yourself.
It’s a bit silly to do that again for every webapplication. So here it is, the logback-webfragment.
The logback-webfragment is a Servlet 3.x webfragment configered to be loaded before other fragments. It takes a location from a web.xml configparameter and loads the configuration from there. Optionally you can add another context parameter to enable one of the 5 default configurations I’ve added.
The idea for the code of the listener is taken from this ticket in logbacks issuetracker. Currently logback-webfragment will only work for Java 1.7 and higher. The maven artifact name is named aaa-logback-webfragment. The aaa is there to increase the chance that the webfragment is loaded before others that are also configured to be loaded first.
In analogy to logback itself the webfragments license is EPL. It is not yet in maven central repo. Maybe I have to test it a bit more.