Wednesday, September 4, 2013

JRebel and maven overlays

It was a while ago when I have posted on issues related to using JRebel with Intellij and maven. Today I would like to say few words about web applications.
Actually, I have configured JRebel for the first time because of web apps :). Well, because we couldn't use exploded wars. Can you imagine redeploying heavy war file only to check fix for something as complicated as spelling error ? Well, I couldn't. For this basic scenario default JRebel configuration for web comes in handy. What do we have here ? The classpath space of a war is mapped to target directory whereas web content to source directory. Perfect. Now, every time I save a jsp file the change is reflected on the server. Obviously, JRebel is better than that. For example spring web-mvc is supported thus you can add new mappings to the controller on the fly.

Overlays

The maven-war-plugin comes with the overlaying feature. Overlays (when over-used) are pure evil ;), but sometimes you cannot do much about it. I will try to picture the idea with very simple example. In the figure you have two projects: web1 and web2. You can download the code from Github - last update contains the changes from current post.
I have configure the overlays to merge web2 module into web1. This can be achieved with configuration listed below. The empty overlay block is this handle so points to web1 project. As a result the resources from web2 will overlay web1's resources in case there is no exclusion specified. In the figure exclusion is marked with grey spot. As you can see the resulting war contains some resources from web1 (blue spots) and web2 (red spots). The resources from web1 are these excluded in configuration or not included in web2 module. The content of target war (only jsp's for simplification) is shown in the figure on the right. There are two files from web2 module and one from the web1 module. Ugly. In fact we have hello.jsp file in both modules.You can check the content of the web page after build & deploy procedure. When you point your browser to the action that results in hello.jsp you will see the content of the file from the web2 module.
Let's try it now with JRebel. For this experiment I will use configuration from the listing above. To run the server with JRebel you need to modify the run script or provide environment property. To enable JRebel for JBoss I have modified standalone.conf.bat adding set "JAVA_OPTS=%JAVA_OPTS% -javaagent:E:\path_to_rebel\jrebel.jar" to the configuration. After server restart you will see different content under the same location. It happened because the web folder from war is mapped to source folder in web1 module.

Modifying JRebel configuration

Lets try to achieve expected behaviour. JRebel configuration allows to add multiple directories, which is presented in the listing below. Using this configuration you should see following log messages in server log: So does it work as expected ? Nope. The content of hello.jsp from web1 module is rendered. You can try to reorder dirs in rebel.xml which helps from time to time. Actually, I was not able to reproduce this problem. I though I can pinpoint the problem playing with bigger project at work but here it works in 80% of cases. Anyway, situation is better than before. Now we are able to edit page3.jsp from the second module.
Fortunately, we can be better than that and provide a configuration that is compatible (and stable) with our overlays. When we define two link blocks the ordering from xml is preserved. So in this case web block looks like that: In case, this doesn't work for some specific version of JRebel there is only one thing you can do before bursting into tears. You can use include exclude blocks to shape the final JRebel mapping.

Final note

Web overlay mechanism is evil. You need know how does it work. You need to know locations of the files and the relations (especially overwrites) between them. When it comes to JRebel ... I wish directory definition is stable and better documented.

What comes next

In case you use the source project, you've probably got some problems with the configuration. There are full paths defined which work in my configuration and not necessary in yours. Next, time when talking about JRebel + maven I will share my opinion on how to survive sharing such a project within a team.

1 comment:

Unknown said...

It is possible to define placeholders in the paths configured in rebel.xml as ${some-property-name}, which can be expanded using -Dsome-property-name JVM argument.

This would help you to share the configuration with the team, in case if you wish to keep rebel.xml in version control.

However, if the configuration is generated by maven plugin, then this is not a big issue - every team member would just execute maven goal instead.