Rafael Sanches

February 2, 2012

Spring-mvc + Velocity + DCEVM

Filed under: java, performance, server-side, spring, tutorial — mufumbo @ 5:54 pm

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"
        <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">
                <entry key="dateTool"><bean class="org.apache.velocity.tools.generic.DateTool" /></entry>
                <entry key="escapeTool"><bean class="org.apache.velocity.tools.generic.EscapeTool" /></entry>

    <bean id="velocityConfig"
        <property name="configLocation" value="/WEB-INF/velocity/velocity.properties" />
        <property name="resourceLoaderPath">
        <property name="velocityProperties">
                 <prop key="contentType">text/html;charset=UTF-8</prop>

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


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:

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:



Hello ${world}.


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:

run-jetty-run dcevm velocity

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.


  1. Why dont you just use jboss to serv your apps?
    It doesnt requires restarts when you deploy a new set of classes, there is this feature called hot deploy.
    Would there be any aspect in tomcat that is better to your enviroment?

    Comment by newprogrammer — February 10, 2012 @ 10:10 am

    • If you think about it, jboss uses tomcat internally. In my examples I’m not using heavily the J2EE components, like EJB etc.

      Even with jboss you would need a solution like DCEVM or JRebel if you add new classes or change a method signature. Jboss would restart the server.

      I don’t know if there would be any benefit in using jboss rather then using spring + tomcat directly.

      Check this out: http://radio-weblogs.com/0135826/2004/05/17.html#a30

      Comment by mufumbo — February 10, 2012 @ 1:50 pm

      • Did you try this with application servers like websphere? I mean I tried installing it with IBM JDK ,but it is not recognizing it . I am looking for workarounds for the same.

        Comment by Sherin — March 27, 2012 @ 8:19 pm

      • Hi Sherin,

        I only use DCEVM for debugging when developing. This shouldn’t be used in production at all.

        I don’t understand when you say that you’re using with IBM JDK, since you should really use the modified JVM (soylatte if you’re using MacOSX).

        I use Jetty as described in the blog post, but it probably work with websphere as well. Depending how you run it.


        Comment by mufumbo — March 27, 2012 @ 8:27 pm

  2. does DCEVM work for jsps, I am having hard time getting jsp changes reflected, not sure how to configure. I have a tomcat webapplication outside of Eclipse, the jdk/jre used by eclipse and tomcat are the same modified by DCEVM.

    Comment by merlin — April 21, 2012 @ 2:31 pm

    • Hi Merlin,

      Yes, the JSP’s should work just fine! I suggest you to use the jetty configuration as explained in this tutorial. It rocks!!!

      I’m not sure what can be happening with your tomcat instance. You may have something configured in tomcat to restart the webapp if there’s a new version?


      Comment by mufumbo — April 21, 2012 @ 4:44 pm

  3. […]  one of the greatest JAVA Web developers pain into a line of business.  However there have been alternatives but none so simple as […]

    Pingback by Spring Loaded – No more restarting JVM!! | Javasight's Weblog — October 25, 2014 @ 4:59 pm

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: