Spring-mvc + Velocity + DCEVM

Java web development can be frustrating at times. Things that slow me down:

• Excessive pre-configuration to be able to deliver results
• Many people use JSP’s in a confusing way and end up with mixed patterns in the views.
• Server restarts and deployment kill my productivity.

In order to improve dev speed I have been using these three technologies together:

• Spring-MVC: This one makes it easier to bind controllers and views together, simply using annotations. This makes it very easy to create well defined controllers before the execution of the view.
• Velocity: One of the most simple and powerful template engine available. With this I can define clear and simple templates that can access and interact with Java objects at the runtime.
• DCEVM: Dynamic Code Evolution VM. A modification of the Java HotSpot(TM) VM that allows unlimited class redefinition at runtime. In our case it will enable to deploy changes in java classes without restarting the servlet container.

Since there are many tutorials on how to use these technologies singularly, this post will only cover how to bind these three technologies together. I would also suggest the usage of Maven to glue the dependencies together.

Lately many people are excited about the Play Framework which adds speed to Java development. Personally, I don’t like being too tight to a framework, but it seems very good.

I would recommend veloeclipse eclipse plugin for coloring the templates.

Glueing Velocity With Spring

There are many tutorials covering this part, like this one from velocity and this one from spring, but no one of them talks about WebappResourceLoader and how to use relative paths in the velocity templates and in the controllers.

Here’s the spring configuration that I use:

    <bean id="viewResolver"
        class="org.springframework.web.servlet.view.velocity.VelocityViewResolver">
        <property name="cache" value="true" />
        <property name="prefix" value="" />
        <property name="suffix" value=".vm" />
        <property name="toolboxConfigLocation" value="/WEB-INF/velocity/tools.xml" />
        <property name="exposeRequestAttributes" value="true"/>
        <property name="exposeSessionAttributes" value="true"/>
        <property name="exposeSpringMacroHelpers" value="true"/>

        <property name="attributesMap">
            <map>
                <entry key="dateTool"><bean class="org.apache.velocity.tools.generic.DateTool" /></entry>
                <entry key="escapeTool"><bean class="org.apache.velocity.tools.generic.EscapeTool" /></entry>
            </map>
        </property>
    </bean>

    <bean id="velocityConfig"
        class="org.springframework.web.servlet.view.velocity.VelocityConfigurer">
        <property name="configLocation" value="/WEB-INF/velocity/velocity.properties" />
        <property name="resourceLoaderPath">
            <value>/</value>
        </property>
        <property name="velocityProperties">
           <props>
                 <prop key="contentType">text/html;charset=UTF-8</prop>
           </props>
          </property>
    </bean>

It’s very important to use  org.apache.velocity.tools.view.WebappResourceLoader in order to facilitate development.

Using ClasspathResourceLoader makes development painful because depending on your configuration it won’t reload the templates when you’re changing, or sometimes it will refresh the entire webapp context in order to refresh a single template. This process can take you minutes after each template change.

Here’s my configuration for velocity.properties:

runtime.log.invalid.reference = true
runtime.log.logsystem.class=org.apache.velocity.runtime.log.CommonsLogLogChute

input.encoding=UTF-8
output.encoding=UTF-8

directive.include.output.errormsg.start = 

directive.parse.max.depth = 10

velocimacro.library.autoreload = true
velocimacro.library = /VM_global_library.vm
velocimacro.permissions.allow.inline = true
velocimacro.permissions.allow.inline.to.replace.global = false
velocimacro.permissions.allow.inline.local.scope = false

velocimacro.context.localscope = false

runtime.interpolate.string.literals = true

resource.manager.class = org.apache.velocity.runtime.resource.ResourceManagerImpl
resource.manager.cache.class = org.apache.velocity.runtime.resource.ResourceCacheImpl

resource.loader = webapp, class

class.resource.loader.description = Velocity Classpath Resource Loader
class.resource.loader.class = org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader 

webapp.resource.loader.class = org.apache.velocity.tools.view.WebappResourceLoader
webapp.resource.loader.path = /WEB-INF/views/
webapp.resource.loader.cache = true
webapp.resource.loader.modificationCheckInterval = 2

Now you can start writing a simple java controller:

@Controller
public class MyControllerClass {
    @RequestMapping(value = "/my-url-path/{myPathVariable}", method = RequestMethod.GET)
    public String processRequest(@PathVariable String myPathVariable, @RequestParam(required = false) Long editId, Model model) {
        model.addAttribute("world", "world");
        return "/pages/forum/admin/forum-create";
    }
}

Now you can create simple velocity view with a templates like:

#parse("/parts/header.vm")

#parse("/parts/left-menu-p.vm")

Hello ${world}.

#parse("/parts/footer.vm")

Notice that no XML configuration was necessary, just the creation of the view and the controller. Also, thanks to DCEVM, there’s no need to restart the webapp after creating a new controller.

After configuring spring-mvc + velocity, the most important part is to configure DCEVM in order to not need to restart our tomcat container after every change in the classpath.

Configuring DCEVM

First download the binary from http://ssw.jku.at/dcevm/binaries/

If you’re in a windows or linux environment, just open the jar and choose the JDK that you want to have the modified VM running. Notice that you can enable and disable DCEVM support for that JDK. On Linux only the 32-bit JDK is supported.

If you’re running MacOSX you’ll have to download the 32-bit version of the Soylatte VM. This is available here: http://landonf.bikemonkey.org/static/soylatte/bsd-dist/javasrc_1_6_jrl_darwin/soylatte16-i386-1.0.3.tar.bz2

Unzip the soylatte VM under /Library/Java/JavaVirtualMachines/soylatte16-i386-1.0.3/

Now just run the dcevm-0.2.jar and choose /Library/Java/JavaVirtualMachines/soylatte16-i386-1.0.3/

After setting up the new VM we need to setup the eclipse project.

1. Select the project properties and use the new JRE.
2. Download tomcat and create a new server in eclipse, choose tomcat.
3. Make it sure that your tomcat run in your newly created JRE.
4. Open the new server configuration and make it sure to check “Automatically publish when resources change”
5. Go to the server “modules” tab and edit your project web modules. Disable “Auto Reload”. This is extremely important since it will save you hours and days of restarting time.
6. Just run your tomcat and every time you make a change on your project it will be pushed to the server. No need to restart!

For a more compreensive tutorial about how to configure tomcat + eclipse, please visit: How to Set Up Hot Code Replacement with Tomcat and Eclipse

If you like the DCEVM idea, also take a look into jRebel, which is even more powerful.

Also, if you use the Datanucleus JDO database, don’t forget to install the JDO eclipse plugin, in this way your classes are compiled on the fly after changes, so no need to restarts for enhancement.

Configuring Run-Jetty-Run Eclipse Plugin

Another simpler way is to install the Run Jetty Run plugin and run it over the new soylatte jvm. When creating your debug profile, remember to click in the JRE tab and choose the Soylatte VM. Running a jetty container with this plugin is 20 times faster than making a “mvn jetty:run”.

Install the plugin from their update site: http://run-jetty-run.googlecode.com/svn/trunk/updatesite

After the plugin is installed, remember to enable build automatically and disable source scanner in the jetty plugin:

This will make it possible to save your java files and velocity templates without restarting the server. One cool configuration that I’ve made on mine is that I added the spring and velocity configuration directories to the “Custom Scan Folder and Files”, so every time I change any files it will redeploy the webapp. Notice that redeploying the webapp with this plugin is 20 times faster than making a “mvn jetty:run” from scratch.