JRebel, Intellij, and maven placeholders - lessons learned

In my last post I have mentioned that there are some scenarios where using JRebel is not so straightforward. But it does not mean it's complicated. There are three steps needed: think, configure, and run. For those of you who need some sandbox for experimentation there is trivial project deployed to GitHub. There are several revisions that will illustrate the problems and solutions I am discussing.

Think

The rule of thumb (in my opinion) is to work with the smallest deltas possible. Unfortunately, there are different conditions for capturing changes for different types of resources. Fortunately, we can handle most (if not all) of them.

The rebel configuration generated by the IDE plugin maps jar/war/ear config to default location. In case of jars, it is the build (target) folder. I am working with Intellij but my project's layout is defined by maven. Thus incremental changes to java classes are handled easily in the default configuration. Resource (like xml or property files) changes are captured by JRebel only if we update them in the build folder which (to my best knowledge) must be handled by maven. The situation of Eclipse users with m2e plugin on board is a way better as they can configure resource processing triggers.

Alternatively we can adjust rebel.xml configuration. In this way changes are captured as soon as files are saved. But ... This mode is not applicable when we have any preprocessing in resource files.

Finally, we can map several physical locations to a virtual one. There filtering mechanisms allow us to find the most optimal configuration for our needs.

Configure

JRebel can be configured in several different ways. First, the rebel.xml file might be generated by Eclipse/Intellij plugin (from what I've seen plugin for Eclipse is more powerful). Second you may configure maven plugin to generate rebel.xml file for you. Finally, you can just write it by yourself.

In the listing below a simple JRebel configuration for single module is provided: In this configuration the classpath of mod2.jar will be replaced with the content of build directory.

If we want to have to see immediate effect of the resource changes we can use the following configuration: In the above listening we combine the class path from two locations. The resources are monitored in source folder so every change triggers reconfiguration. Classes and other types of resources are collected from build directory. Thus, classes are updated on-the-fly after the recompilation.

Please note that in the previous scenario there will be an exception thrown in case there are maven placeholders in resource files. In this case we need to slightly modify our example. This way we capture instant changes to resource files, and changes to the property file triggered by maven resource processing.

Run

This is it we have chosen and configured our application (maybe in a separate maven profile) to be run with JRebel. Run it from within your IDE, or as agent in standalone mode.

In my next post I will try to describe my observations on using JRebel for maven web modules.

JRebel is great but what to do when you application is not a "typical" one.

I find JRebel a great tool. It may save you some/a lot of time depending on your scenario. There are plugins that allows for on-the-fly reconfiguration of multiple aspects of your application. You can perform a complete makeover to you Java classes, JSP resource, IoC configuration, aspects - to name only few.

I have capture a screencast  for a very simple example. There are few beans that are dynamically reconfigured - as well as the logging configuration.

But what to do with more complex scenarios ? In the following posts (or post) I will try to share my observations on using  JRebel in a project that:

• is developed by multiple developers (using varying tools while maven is common denominator)
• has multi-modular structure and quite few lines of code,
• has several builds modes (e.g. production, development, and testing artifacts with varying configurations are possible)
• uses nasty maven tricks including resources filtering, profiles, conditional configuration, overlaying and many more,
• allows for building different products from partially common code-base

For the moment I will tell you one thing: default configuration is not sufficient here. 

Hibernate filtering behavior with cache.

As you may know there is a possibility in hibernate to handle objects visibility with filtering rules.
There are few issues worth remembering when filtering is combined with cache mechanism:

• the filtering is not enabled by default (so if you want to use it for a session you need to enable filters)
• the filtering bypasses second level cache. 
• the filtering is not applied for Session.get or Session.load methods.