I took some time last weekend and refactored AppFuse to use Spring
to replace my Factories and Hibernate configuration. It only took me a couple of hours, which says a lot for Spring. I was amazed at how many things just worked. It actually lifted me out of my flu symptoms and made me feel euphoric. Or it could have been the Sudafed. In reality, I only replaced one Factory class (DAOFactory) - a fairly large class that instantiated DAOs using reflection and constructor variable inspection. I was also able to get rid of the ServiceLocator class, the getConnnection() stuff in ActionFilter and the hibernate.cfg.xml file.
The one thing I found when looking at the Petclinic and JPetstore apps was that they used an applicationContext.xml file for unit tests, and a (very similar) one for running the app in a container. To me, this was a warning sign. DRY (Don't Repeat Yourself) is a big reason for using XDoclet and I'm beginning to think that Spring could benefit from a little XDoclet lovin'. Anyway, back to the story.
I wanted to find a way to use the same XML files for testing and in-container execution. As you might know from Part I, AppFuse has 3 different tiers: dao, service and web. To run unit tests for the dao and service layers, I simply load a applicationContext.xml file in my JUnit test's setUp() method and go from there. I saw this in the petclinic app and found that it works pretty well. In the end, I decided to setup different XML files for each layer - applicationContext-hibernate.xml, applicationContext-service.xml and applicationContext.xml for the web layer. The main applicationContext.xml uses entity includes to reference the other two files.
The main pain I found was that the entity includes required different paths for tests vs. running in container. Basically, for tests, I had to use:
<!ENTITY database SYSTEM "applicationContext-database.xml">
While tests, using the ClassPathXmlApplicationContext required:
<!ENTITY database SYSTEM "WEB-INF/applicationContext-database.xml">
Using Ant to do a little replace logic allowed me to jump over this hurdle.
Using this setup, any new DAO definitions are added in src/dao/org/appfuse/persistence/hibernate/applicationContext-hibernate.xml, new Manager definitions (and declarative transaction settings) are be added in /src/service/org/appfuse/service/applicationContext-service.xml. The test-specific applicationContext-database.xml sits in the "test" directory and contains the following:
<bean id="propertyConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="location"><value>database.properties</value></property>
</bean>
<bean id="dataSource"
class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="driverClassName">
<value>${hibernate.connection.driver_class}</value>
</property>
<property name="url">
<value>${hibernate.connection.url}</value>
</property>
<property name="username">
<value>${hibernate.connection.username}</value>
</property>
<property name="password">
<value>${hibernate.connection.password}</value>
</property>
</bean>
While the applicationContext-database.xml for the web is simply:
<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName"><value>jdbc/appfuse</value></property>
</bean>
To integrate Spring with my web layer (Struts), I just used the ContextLoaderListener in my web.xml file. I didn't see any point in bringing yet another JAR file into the mix.
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
Finally, to expose Spring's context to my Struts Actions, I added the following to my BaseAction.java class:
private WebApplicationContext ctx = null;
public Object getBean(String name) {
if (ctx == null) {
ctx = WebApplicationContextUtils
.getRequiredWebApplicationContext(servlet.getServletContext());
}
return ctx.getBean(name);
}
|
This way, the UserManager implementation can be easier retrieved using:
UserManager userMgr = (UserManager) getBean("userManager");
|
The best part about the Spring integration in AppFuse is: (IMO) its Hibernate support and how it drastically simplifies my Hibernate DAOs (as if Hibernate wasn't simple enough already). I dig the ability to specify declarative transactions, and this refactoring seems to have reduced the "src" distribution of AppFuse by 2 MB (to 10MB total)! I don't know where this came from since the Spring JAR is almost 1 MB. The appfuse.war is about 500 KB larger, but I can live with that.
Of course, all of this has been checked into CVS if you'd like to take a look.
I tried posting the following to the tomcat-user list, but after not seeing it show up for 2 days, I'll just try it here.
----
I have developed a webapp that uses basic open source stuff (struts, hibernate,
etc.). I've been developing/testing it on the following platforms - where it
works fine and runs lickedy-split:
OS X 10.3, 1.33 GHz, 1 GB RAM
Windows XP, 2.6 GHz, 1.5 GB RAM
Windows 2000 Server, 1 GHz, 512 MB RAM
Windows 2000 Server, 1.5 GHz, 256 MB RAM
All of these are running Tomcat 4.1.29 or 4.1.12. I recently tried to deploy
it to the "test web server" (Windows 2000 Server) at my client and it runs
dreadfully slow. It takes almost 30 seconds to load a page. The main difference
is that the test web server has a 667 MHz CPU. It has 512 MB RAM, and we
upgraded it to 1 GB, but that didn't help at all.
I've recommended we get a faster CPU for the test web server, but I wanted to
confirm that this could be the source of the problem. On this server, and the
1.5 GHz/256 MB RAM machine, IIS is integrated with Tomcat. All machines are
running JDK 1.4.0 or above.
Any help is appreciated.
