The Spring Framework distribution also ships with a number of so-called showcase applications. Each showcase application provides fully working examples, focused on demonstrating exactly one new Spring 2.0 feature at a time. The idea is that you can take the code in these showcases and experiment with it, as opposed to having to create your own small project to test out new Spring 2.0 features. The scope of these showcase applications is deliberately limited; the domain model (if there even is one) consists of maybe one or two classes, and typical enterprise concerns such as security, error-checking, and transactional integrity are omitted deliberately.
This small application showcases implementing Spring MVC Controllers using the dynamic language support introduced in Spring 2.0.
The web application is very simplistic, because the intent is to convey the basics of the dynamic language support as applied to Spring MVC and pretty much nothing else.
There is one Groovy file in the application. It is called 'FortuneController.groovy' and it is located in the 'war/WEB-INF/groovy' folder. This Groovy script file is referenced by the 'fortune' bean in the 'war/WEB-INF/fortune-servlet.xml' Spring MVC configuration file.
You will notice that the 'fortune' bean is set as refreshable via the use of the 'refresh-check-delay' attribute on the <lang:groovy/> element. The value of this attribute is set to '3000' which means that changes to the 'FortuneController.groovy' file will be picked up after a delay of 3 seconds.
If you deploy the application to Tomcat (for example), you can then go into the exploded '/WEB-INF/groovy' folder and edit the 'FortuneController.groovy' file directly. Any such changes that you make will be picked up automatically and the 'fortune' bean will be reconfigured... all without having to stop, redeploy and restart the application. Try it yourself... now admittedly there is not a lot of complex logic in the 'FortuneController.groovy' file (which is good because Controllers in Spring MVC should be as thin as possible).
You could try returning a default Fortune instead of delegating to the injected FortuneService, or you could return a different logical view name, or (if you are feeling more ambitious) you could try creating a custom Groovy implementation of the FortuneService interface and try plugging that into the web application. Perhaps your custom Groovy FortuneService could access a web service to get some Fortunes, or apply some different randomizing logic to the returned Fortune, or whatever. The key point is that you will be able to make these changes without having to redeploy (or bounce) your application. This is a great boon with regard to rapid prototyping.
The samples/showcases/dynamvc directory contains the web-app source. For deployment, it needs to be built with Apache Ant. The only requirements are JDK >=1.4 (it is Groovy that requires at a minimum JDK 1.4) and Ant >=1.5.
Run "build.bat" in this directory for available targets (e.g. "build.bat build", "build.bat warfile"). Note that to start Ant this way, you'll need an XML parser in your classpath (e.g. in "%JAVA_HOME%/jre/lib/ext"; included in JDK 1.4). You can use "warfile.bat" as a shortcut for WAR file creation. The WAR file will be created in the "dist" directory.
This small project showcases using some of the Java5 features in Spring to implement DAOs with Hibernate and JDBC. This project is very simplistic, because the intent is to convey the basics of using the SimpleJdbcTemplate and the @Repository annotation and several other DAO-related features, but nothing else.
The domain in this sample application concerns itself with car parts. There are two domain classes: Part and CarModel. Using a CarPartsInventory car plants for example will be able to query for parts, update the stock of certain parts and add new parts.
Based on a CarPartsInventory interface there are 3 DAO implementations, each using a different style. Two are using Hibernate and the other is using JDBC. The JdbcCarPartsInventoryImpl uses JDBC and the SimpleJdbcTemplate. If you look closely at this DAO you will see that the Java5 features the SimpleJdbcTemplate uses significantly clean up your data access code.
The TemplateHibernateCarPartsInventoryImpl uses the HibernateTemplate to query for Parts and update part stock. This is nothing out of the ordinary if you're used to programming using Spring and Hibernate. The PlainHibernateCarPartsInventoryImpl however does not use the HibernateTemplate anymore. It uses the plain Hibernate3 API to query the session and the database for parts. Of course, the Hibernate3 API does not throw Spring DataAccessExceptions while this was originally one of the reasons to start using the HibernateTemplate. Spring 2.0 however adds an annotation that still allows you to get the same behavior. The @Repository annotation (if you look carefully at the PlainHibernateCarPartsInventoryImpl, you'll see it's marked as such) in combination with the PersistenceExceptionTranslatorPostProcessor automatically take care of translation Hibernate exception into Spring DataAccessExceptions.
The samples/showcases/java5-dao directory contains the project's source. The project only contains unit tests that you can look at apart from the source code. To build and run the unit tests, you need to build with Apache Ant (or run the sample in your favorite IDE). Run ant tests using a Java5 VM (the project uses annotations and generics)