Spring by Example JDBC, Spring Dynamic Tiles Module, and Google Web Toolkit

I almost have everything ready to post a simple Google Web Toolkit (GWT) example with Spring. I have everything checked in and I also had to update Spring by Example JDBC and Spring by Example Dynamic Tiles Module.

Spring by Example JDBC version 1.0.3 was upgraded to match changes in Spring 2.5.5 and HsqldbInitializingDriverManagerDataSource & InitializingDriverManagerDataSource were changed to use SimpleDriverDataSource (which was added in Spring 2.5.5).

Spring by Example Dynamic Tiles Module 1.1 has a number of changes. The project was updated to use Spring 2.5.5, AJAX support like Spring JS and Spring Web Flow is provided, and a few other items (see release notes in the projects README.txt). Also, Spring by Example Dynamic Tiles Module 1.0 was compiled with Java 6, but should have been compiled with Java 5. The projects are basically all ready, but just need a little more testing. Although everything is checked into Subversion.

I'll try to get everything finalized and checked in over the next couple of days. I think the AJAX support that works with Spring JS' Spring.remoting.submitForm is great. It's really nice to have simple and easy control over updating specific div sections that match parts of a Tiles template.

Spring JPA Example with Hibernate

This took longer than I expected since I was able to reuse the Entity beans from the Hibernate annotation example. I had a lot of trouble getting the right jars to work together. Hopefully the Maven config in the project will help someone else.

• One to Many JPA Hibernate Configuration
  

The key things besides the classpath to get setup in the example were just the Spring Config and putting the JPA configuration in META-INF/persistence.xml. Also the LocalContainerEntityManagerFactoryBean actually returns a javax.persistence.EntityManagerFactory. I assumed it returned an EntityManger based on the name of the class.

One other point is that JpaDaoSupport has setEntityManger and setEntityManagerFactory as final. So you can't override them, use @Autowired, then super the value to the parent method. I ended up passing in the EntityManagerFactory in the constructor using @Autowired. Which is probably better since it's required, but I'm used to typically using setters in Spring.

Note: This example has the DAO class extend JpaDaoSupport and uses the JpaTemplate, but Spring recommends the native JPA style of coding.

"JpaTemplate mainly exists as a sibling of JdoTemplate and HibernateTemplate, offering the same style for people used to it. or newly started projects, consider adopting the native JPA style of coding data access objects instead, based on a "shared EntityManager" reference obtained through the JPA @PersistenceContext annotation." (from Spring 2.5.x JPA documentation)

Spring Config with Zero XML

So, if you really don't want to use any XML to configure Spring and you also don't want to use the Spring JavaConfig project (create beans using Java code), you can actually use annotation-based config. I found this looking at the context:component-scan unit tests. You just create a GenericApplicationContext and a ClassPathBeanDefinitionScanner. Then call refresh on the context load the bans and register a shutdown hook so you get destruction callbacks on your beans when the JVM is shutdown. The ClassPathBeanDefinitionScanner registers the @Autowired and @Required bean post processors. It also registers the JSR-250 Commons Annotations and the PersistenceAnnotationBeanPostProcessor for JPA if their jars are in the classpath. It's pretty straightforward.

Also it could be a good way to unit test how many beans are being pick up by the context:component-scan in case you're worried you configured the packages it's scanning incorrectly.

A downside to this is that if you are using the Spring IDE in Eclipse, you won't be able to register an XML file with it. The latest version handles XML configured beans and ones that are scanned so you can get consolidated bean graphs and all the other help it provides. I personally wouldn't do this and it's worth having a very, very small XML file just to define context:component-scan directly.


String basePackage = this.getClass().getPackage().getName();

GenericApplicationContext ctx = new GenericApplicationContext();
ClassPathBeanDefinitionScanner scanner = new ClassPathBeanDefinitionScanner(ctx);
int beanCount = scanner.scan(basePackage);

ctx.refresh();
ctx.registerShutdownHook();

Spring In-depth, In Context

I've been working for a while on a book for Spring 2.5. I've decided to post it for free online and hopefully it will be useful to people. It currently has a very good introduction to Spring, basic bean creation using XML and Annotations. Although the Annotations chapter isn't 100% complete. There are also partially complete chapters on resources & ApplicationContexts and AOP.

As updates are available, I'll continue to post them. I decided since there was a lot of information and examples done, it was better to release it now and continue to work on it when I have free time. I hope it helps people. It was a lot of work getting even this much done. There are so many nuances to Spring's configuration options between XML and Annotation-based configuration.

Also, a very special thanks to Susan Kerschbaumer who has co-authored the book with me and has personally done a really excellent job with what she has done so far. Currently Susan has only had time to work on the Preface, Chapter 1, and Chapter 2. But as she has time she will focus on other chapters.


Spring In-depth, In Context

• Preface


• Chapter 1: Spring In Context: Core Concepts


• Chapter 2: A Practical Introduction to Inversion of Control


• Chapter 3: In-depth Inversion of Control (IoC) [Draft]


• Chapter 4: Annotation-based Bean Configuration [Draft]


• Chapter 5: Bean & Resource Loading [Draft]


• Chapter 6 :AOP [Draft]