Adding external template locations to Dropwizard

Earlier in the year, as part of my work for Flax, I re-visited a project I had last worked on around two-and-a-half years previously. The client had a library comprising documents and reports of various types, which were entered and modified by hand. The data entry templates needed to look as similar to the source documents as possible, as did the documents when viewed on-screen. (The documents were also output back into external formats, in this case Word and PowerPoint documents, but that’s an aside to this post.)

We had known when the project was initially specified that the types of document might evolve over time – new forms and report types would be added, and older ones rendered obsolete. The project had been put together using Dropwizard, using its Views bundle to handle the form and report templates, all bundled up in a big Jar file which ran from the command line (or as a Windows service in this case).

Unfortunately, the only way to modify the document templates was to unbundle the Jar file, make the changes, and then bundle it back up again – this had seemed like a good idea at the time, but assumed much more depth of knowledge than the client were ultimately comfortable with, even though I’d cheerfully written page after page of documentation explaining how to do it.

So, how could we make this easier? The obvious solution was to pull the form and report templates out of the jar file, putting them in a secure location where the client’s technicians could modify them without having to dismantle and re-assemble Jar files.

As mentioned above, the project had been built using Dropwizard, which we use a lot due to its flexibility and ease of configuration. It makes an excellent middle layer between client code and a data store (generally either Solr or Elasticsearch), and does a good job of serving dynamic pages when asked. It would have been very difficult at the time to implement this project using a purely JavaScript front-end, mainly due to the dynamic nature of the reports – there were no restrictions on the fields that could be used or added, so populating the forms would have been tricky.

However, one place where Dropwizard is not so flexible is when specifying template locations. Templates are expected to be inside the application jar file and this cannot be overridden using the default configuration options. I found myself cut-and-pasting chunks of code out of the DropWizard source purely to allow an external template location to be specified. Ultimately, it worked but felt messy.

The client’s application was built using Dropwizard 0.6.2. I wanted to find out whether it would be easier to make these changes in a more recent version, so grabbed a copy of 0.9.2, the latest full release at this time (there are 1.0 release candidates, but I wanted the stability of a full release).

I set myself the task of building an example application which could use external templates, for both of the template systems available to Dropwizard out of the box (Freemarker and Mustache), extending the default DropWizard classes as necessary.

The result can be found at This contains enough code to use as a basis for a later application to use external templates if necessary, while still allowing for the default behaviour if not requires. It does require some specific configuration for the views, and I had to add a configuration class to solidify how the template paths would be passed in. Unfortunately, there is still quite a lot of duplicate code in the renderer classes – this seems unavoidable due to how the original renderers have been written (I don’t imagine this kind of extension was expected).

Feel free to check out the example application – suggestions for improvement will be gratefully received!