Introduction I had an interesting conversation the other day about custom domain-specific languages and we happened to talk about a feature of Spring that I’ve used before but doesn’t seem to be widely known: the static application context. This post illustrates a basic example I wrote that introduces the static application context and shows how it might be useful. It’s also an interesting topic as it shows some of the well-architected internals of the Spring framework.

Introduction One of the nice recent features of Spring (2.x era) is support for custom XML. This is the way that Spring itself has added all kinds of new tags such as <util:list> and <mvc:annotation-driven>. The way this works is pretty elegant, to the point that it makes an interesting alternative for configuring Java using XML, particularly if the application already uses Spring. I’ve written an example application to try to give an easily-copied example of how it’s done.

Last time I introduced an example application I wrote to illustrate Spring WebMVC for a Java class. I think the application is a nice example because it also illustrates the ability to add a REST API to an existing standalone Java application using Jetty as an embedded servlet container. I’m presenting this example in a series of posts because I learned from personal experience teaching this that the more “under the covers” behavior there is, be it classpath scanning, annotation configuration, reflection, or proxying, the harder it can be for new folks to grasp.

While giving a series of presentations on using Java in a distributed environment (focusing on Java EE and Spring), I got a lot of interest in web programming. I did an extra presentation on servlets, but I didn’t want to leave it there, because writing Java servlets directly is not very efficient compared to tools like Spring WebMVC. So I made an extra presentation on WebMVC, which led me to make a sample application that provides both a client and a server using Spring WebMVC.

This is part 1 of 3. Also see part2 and part3. There are a lot of tutorials out there about providing REST web services in a servlet container by building and deploying a WAR. There are also cases where someone is looking to put a REST interface on an existing Java application. In that case it isn’t always possible to turn the application into a WAR or EAR and adding a servlet container as a separate process just adds a layer of complexity.