Blog

Today we’ve released JRebel 4.0 RC1, which includes even more improvements to EJB support and a few fixes in Spring integration. Also an initial integration for Metro, JAX-WS reference implementation, is included. What are you waiting for? Download the new version now!

EJB integration now includes the support for Oracle WebLogic 10.3 and has been tested with several 10.3.x versions. You can now add new EJB component and inject it to other deployed EJB without having to redeploy the application. With the latest changes, adding new EJBs is supported on JBoss 4.2/5.1, Glassfish 3.0/3.1, WebSphere 7 and WebLogic 10.3 application servers.

Now, it is just a few strokes left to make JRebel 4.0 final and shiny!

What began two years ago in the far northern country of Estonia as an attempt to re-invent production updates has culminated into the today’s release of LiveRebel 1.0. Already managing a multitude of production environments, it’s best described by the following tagline:

Java EE Hot Update Done Right. No downtime. No lost sessions. No OutOfMemoryErrors. Fully automated. Instant.

LiveRebel represents a quantum leap over all currently available technology for updating Java EE applications.

  • A fully scriptable server and web console that can manage single-node, clustered or cloud Java EE applications of any size on any container.
  • Versions each class and resource individually instead of reloading the whole application, avoiding the problems associated with container redeployment and rolling upgrades.
  • Roll out updates instantly and opaquely to the users. Code is updated in-place, preserving all existing state.
  • Uses an all-Java JVM plugin (-javaagent) on the nodes causing a 3-5% performance overhead.

In a recent survey we did, we saw that only 27.4% of over 600 respondents were satisfied with the update process of Java EE applications. The rest cited multiple issues with container redeployment, lack of tooling and automation as well as lack of industry-standard processes. With the release of LiveRebel 1.0 we can finally offer a solution to this industry-wide problem.

To learn more about LiveRebel you can see the 5-minute screencast, read the overview or just download the free 90-day evaluation. LiveRebel 1.0 is an annual subscription that costs $200 per JVM instance in pre-production and $600 per JVM instance per year in a production environment. For mission critical operations, please contact sales@zeroturnaround.com for a customized quote.

JRebel 4.0 M2 is available for download!

We are continuing to improve the EJB support. With the new version of JRebel 4.0 M2 you can now add new EJBs and references to EJBs while developing with WebSpere Application Server (7.0/6.1). Also, the support JBoss Seam and Spring Security has been improved and Hibernate Validator plugin is included. See the changelog for the list of other fixes and improvements.

Besides that, the nightly build is now also based on 4.0 branch.

As we enter the final race to the stable release of LiveRebel we’re happy to announce that  the LiveRebel 1.0 RC2 have passed all tests and has been uploaded to liverebel.com from the ZeroTurnaround Tartu labs.

This release doesn’t introduce any new features. We’ve fixed several small issues, run our product on an even larger testsuite and tweaked the UI here and there. If you are testing out LiveRebel be sure to upgrade. We are on track for 1.0 release on 17th May, stay tuned.

Hi guys!

Last week I asked you to help me find out how Java EE apps are updated in production. I’d like to thank everyone who replied to the survey so far. I’ve received just over 600 responses so far, and I’m hoping to get a few hundred more to be sure of the data. Here are some interesting things that came out:

  • Only 27.4% of respondents consider the update process ideal. The grievances include lack of tooling support, lack of automation, erratic behavior and many others.
  • Redeployment in production is allowed by as many as 24.2% of respondents, but only 12.2% use it as the primary means of application update. When asked for the reasons, 31.9% of respondents quoted the memory leaks and resulting OutOfMemoryErrors, whereas 46.8% quoted memory problems in addition to other issues with the redeployment.

To find out more today fill in the survey and you’ll see the running tally right away.

Thanks!

Our CTO, Jevgeni Kabanov, is running a survey on app updates in production. Help him finish his PhD and us to understand better what is going on by taking 5 minutes and answering the 14-question survey. Here’s what he writes about it:

***

Hi guys! My name is Jevgeni Kabanov and I’m a computer scientist/hackerpreneur. Recently I’ve been trying to figure out what is happening in the world of Java EE production deployment and frankly it seems pretty scary. After speaking to over a 100 people these are my hypotheses:

  • Nobody uses redeployment in production (as in the actual button that does in-server update). It just isn’t reliable enough due to OutOfMemoryError-s and other failures.
  • The common way to update an application is to:
    • Take all servers down at 2am and hope no one is using it.
    • Take servers down one at a time, upgrade them and either drop or migrate the user sessions.
    • Use weird hacks like copying one file at a time.

I’m also trying to find out how the update process happens, how hard it is and what does it cost in human measure (hours) and in soulless business measure (dollars).

I ask you to help me out and provide me with some semi-solid data I can use to better understand what’s going on in reality. Hopefully you’ll prove me wrong. Afterwards, I’ll make all the data I’ve collected publicly available.

Share your information here

The survey is completely anonymous and the email will only be used to send you the results.

So, please go ahead and fill in the answers. If you have any questions, let me know at liverebel@zeroturnaround.com

We released JRebel 3.6.2 this week! Grab it now!

After the JRebel 4.0-M1 release we’ve spent some time porting some of the features to 3.6.x branch. Here are some of the most interesting features included:

  • Hibernate Validator, which is the reference implementation for JSR 303 – Bean Validation. Actually, this feature was requested by the community, so we hope it will make our users happy!
    With the dedicated JRebel plugin it is now possible to add/edit/remove Bean Validation constraint annotations on bean classes and parent constraint annotation types (i.e., supports composite constraints). And also it is possible to create and edit custom Bean Validation constraint annotation types.
  • JBoss Seam 2.x improvements. A long requested feature that some users asked on our forum – adding new components to components.xml file.
  • Adding new EJB for JBoss 4.2/5.1 and Glassfish 3.x. This feature is ported from 4.0-M1. You can add new @Stateful/@Stateless beans to your app and start using the from the other deployed beans.
  • Debugger integration improvements. We’re catching the corner cases for the debugger integration of JRebel to make the debugging experience as smooth as possible.

The full list of what we’ve added to 3.6.2 version compared to 3.6.1 can be found in the changelog.

Too excited about the release to read the post below? Download the JRebel 4.0M1 release now!

We’ve been working hard to bring you the mind-blowing features in the major version of JRebel. Take a look at the highlights:

  • Integration with HotSwap. Some time ago, in the Reloading Java Classes blog series Jevgeni described the difference of the approach taken by JRebel in regards to HotSwap. Now we want to bring the best of both! For you this will mean some improvements in performance now and major improvements in performance down the line as we take more advantage of this.
  • Support for anonymous class renaming. A common problem for apps that use a lot of anonymous classes is that when you add a new one, the rest get renamed and JRebel would bail due to extended superclass or implemented interface changes. JRebel is now clever enough that it can track such renames and cope with the reloads more gracefully.
  • Adding new EJB 3.х. The M1 version of JRebel 4.0 comes with the fresh integrations for JBoss (4.x/5.x) and Glassfish (2.x/3.x). Now you can add a new POJO to your application on the fly, annotate it with @Stateless or @Stateful, and inject it to the other managed bean. How cool is that!? The rest of containers will follow in M2.

Besides the main features there’s a list of improvements that cannot be neglected. Please take a look at the changelog for the full list of changes provided with the new version.

Ok, so you read it after all. Download the JRebel 4.0M1 release.

At ZeroTurnaround, we like to build products that challenge the status quo.  We have a strong history in supporting Java development teams, but today we’re announcing a step towards supporting Java operations and production teams as well.  It goes like this:

A very common issue in software development is the risk that when you apply a change to a live application, somehow that change may break it – and create a major headache. As deployment in a Java cluster environment is often an expensive process, this commonly leads to lengthy testing and rigid processes that decrease this risk.

We envision managing this risk differently, and we’re now taking our ideas public: today we’re announcing the LiveRebel Public Beta.

LiveRebel is a web console, command line utility and REST API that can version multiple servers and deployed applications at the same time. Instead of the usual deployment process, LiveRebel versions classes and resources individually, allowing instant updates across the cluster while preserving all state, including user sessions. If you don’t like the change you made for any reason, you can roll back instantly.

Under the hood, LiveRebel uses RebelTech, first developed for JRebel (which has been tried, tested, and proven solid by over 10,000 customers), to version the application classes and resources directly. RebelTech allows code and resources to be updated in place, instead of starting a fresh version of the application side-by-side. Due to RebelTech’s integration with JVMs, application servers and frameworks, all application state and user sessions are preserved, without the slightest pause.

Since RebelTech has some limitations to updating classes and cannot create new state (e.g. new fields on existing objects will be null) we intend LiveRebel to be used for smaller updates and fixes. To ensure that every update is compatible, we bundle a sophisticated comparison tool that will ensure that you can roll out and roll back an update safely.

Overall, if you’re interested in updating your live application instantly, then read more about LiveRebel or try it right away.

Wow, we’re on a roll! Just a couple of months ago we released JRebel 3.5, with lots of OSS framework support goodies and now a new major release that reworks all three of the major IDE plugins and includes a ton of other improvements.

The biggest piece of news is that JRebel is now available (and featured) on the Eclipse Marketplace. This means that you can install JRebel from Eclipse with just one click and update through the usual Eclipse channels. On top of that, we’ve improved debugging behavior for Eclipse and IntelliJ IDEA, specifically, stepping now behaves 100% as you would expect. We are also putting final touches on the new and shiny NetBeans plugin, which includes all the features on par with the other two IDEs. It will make the NetBeans Plugin repository sometime in the next two weeks.

As for the other stuff, we have a ton of improvements for GlassFish, JSF Mojarra, Lift, Stripes and Spring MVC Portlets as well as a ton of bugfixes in the changelog. Also, our Enterprise customers will be happy to know that the license server now provides failover.

Search for “JRebel” in the Eclipse Marketplace or just download it now!

« Newer Entries | Older Entries »

Join the Rebellion Facebook Twitter RSS feed