Tag: JRebel

Faster Java based WCMS development

Faster Java based WCMS development

By | | Comments 0 Comment

As I’ve mentioned in my last technology post, I’ve now also tried to use JRebel with a WCMS system, namely Day CQ5.3. It’s based on Apache Sling which uses Apache Felix as OSGI Container and a JSR-283 compliant java content repository to persist it’s content/data. Our basic approach to write components, services, tags and so on is to add all logic (java classes) into a OSGI bundle and deploy that on Felix. All the stuff that is needed to generate the view (jsp, xslt) is saved directly into CRX, the JCR of CQ5. So to load a page, two different classloaders are used, first DynamicRepositoryClassLoader (Sling/JCR) which loads the jsp out of the repository and then instantiates a class (for example for a tag) that is served by the OSGI bundle, for which FelixModuleClassLoader is used.
As you can read on www.zeroturnaround.com, Felix with JRebel is beta support, so why not try to use it with CQ at least to eliminate the deploy process of the OSGI bundle?

The result first: after a couple of mails with Lauri Tulmin from zeroturnaround, it finally worked.

My configuration:

  • In my maven project, I saved rebel.xml under src/main/resources, it contains the path to the classes folder of my eclipse workspace.
  • In the pom.xml of the project, I had to add the following line
    <Import-Package>*,org.apache.sling.jcr.api;version=2.0.4,org.apache.sling.jcr.resource</Import-Package>
    to the maven-bundle-plugin configuration
  • In the start script of CQ, I added the following parameters:
    CQ_JVM_OPTS="-noverify -javaagent:<path to jrebel>/jrebel.jar -Drebel.packages_exclude=sun.reflect"

The parameter -Drebel.packages_exclude=sun.reflect is a kind of a workaround of a JRebel bug, in the newest version it shouldn’t be necessary anymore.

With this configuration I can save my java files in Eclipse, reload the page and the changes are immediately viewable.
For now, this configuration isn’t tested in productive work. We plan to use it in the next couple of weeks and will for sure find some pitfalls… (hopefully not, but you know… 😉 )

I’ve also tried to write an own JRebel plugin to patch the Sling/JCR Classloader, but at the moment it’s not that stable to use it in productivity. You can find some Integration-Javadocs about that on the webpage of zeroturnaround.

JRebel in Action

JRebel in Action

By | | Comments 2 comments

Motivated by the talk Do you really get class loaders? from Jevgeni Kabanov @devoxx in Antwerpen, I’ve downloaded the demo version of JRebel this evening.
JRebel promises faster and much more pleasant Java application development because of mapping the project workspace directly to a running application. That means that no more long deployment procedures (mvn clean install…) are necessary for simple code changes. And it should also work with my current technology stack… Sounds pretty cool, doesn’t it?

So I downloaded the demo version (as a devoxx visitor, I also got a free personal license 😉 ) and installed it. Yes, you read correct, it’s an installer that leads you step by step through the configuration. Probably 20min later, my SpringSource Tools Suite is ready for the first test; I start the server (Tomcat 6.0) and change a jsp (not big business). Oh; it works. Then, a java class, a .properties file, and finally the applicationContext.xml. Just save the file and reload the webpage and it works… feels like developing in the good old php times.

I’ve tried this with a small Spring application. The deployment only takes a couple of seconds, but even then JRebel really gives you a benefit, it’s just more fun to develop 😉
There are also limitations, replacing superclasses and adding/removing implemented interfaces doesn’t work, for that a deployment is still necessary.
Really interesting will it be to try it out with larger applications like WCMS systems for which the deployment takes much longer. More about this may be in the next post 😉