Raible Designs

AppFuse 1.3 vs. 1.4

Mike Lawrence (the guy who wrote the AppFuse on Orion tutorial), sent me an e-mail yesterday asking about AppFuse 1.3 (the latest release) vs. 1.4 (still in CVS).

Spring
This looks like a pretty new framework. I wonder how stable it is? 

How far along are you with 1.4? You've made more changes to 1.3 to move
to 1.4 than I've made to 1.3. So, I'd be better off just taking your 1.4
base and integrating my changes.

Did you eliminate struts as the MVC framework?

Doesn't this invalidate your awesome AppFuse tutorials?

I'd really like to stay in sync with your new release, however, I've got
major production deadlines to meet. It would stink if I automated a
bunch of stuff for 1.3 that you couldn't use in 1.4. Yet, if I move to
1.4, will I be facing stability issues and no tutorial docs?

I figured it'd be better if I answer his questions here, as other folks might be wondering the same thing.

Spring - how stable is it?

As with most open source projects, the version number doesn't always indicate the stability of a product. Roller hasn't reached 1.0, but I would venture to say it's a mature and stable product. If you asked this question on the Spring mailing list, you'd likely received a lot of responses saying that it's very stable and used in many production systems. IMO, it's a very stable framework and likely to be the next Struts (in terms of popularity). I don't know that it's MVC framework will be that popular, but it's persistence support classes, declarative transactions and AOP framework are pretty slick. The fact that it integrates smoothly with all leading MVC frameworks is a nice touch too.

I think the best answer is - you need to work with Spring and then decide for yourself. I love writing one-line DAO methods for Hibernate...

How far along are you with 1.4?

If you're already started an application with AppFuse version x, then you should stick with AppFuse version x until your project is finished. It's often a real pain to upgrade an existing app to use the latest stuff, and probably unlikely you'll gain that much value. However, if you're not under a tight deadline - and you really need something in a more recent release - it makes sense to upgrade. The tutorial I wrote on upgrading a 1.3 app to 1.4 is probably a one-time thing. I don't plan to do an upgrade document between all releases.

That being said, if you have enchancements for AppFuse and want me to roll them into the main code base, the best way is to create patches for the CVS version and then it'll be easier for me to figure out what you changed.

Did you eliminate struts as the MVC framework?

Definitely not - Struts will remain as the standard MVC framework because it is the most popular and most AppFuse users will likely use it. When I add MVC alternatives, they will be packaged similar to the iBATIS option - so you'll have to install them. Most MVC options will likely rip out Struts and replace it with their own stuff.

Doesn't this invalidate your awesome AppFuse tutorials?

The tutorials will be updated to support the latest release. I hope to have some time in early March to update these. As soon as I do, I'll release 1.4.

I'd really like to stay in sync with your new release, however, I've got major production deadlines to meet. It would stink if I automated a bunch of stuff for 1.3 that you couldn't use in 1.4. Yet, if I move to 1.4, will I be facing stability issues and no tutorial docs?

Staying in synch with AppFuse as I push out new releases is probably a waste of your time. I did it with Struts Resume for a long time, and it's a lot of work trying to keep up. I firmly believe that each release of AppFuse has been a solid one - they just keep getting better. The only reason to upgrade is for new features and/or bug fixes. I believe that 1.4 will be just as stable as 1.3 and there will be tutorial docs when its released. As far as your automation stuff, the best way to get that added is send me patches against CVS.

BTW, Mike has integrated Middlegen into his AppFuse-based project. He's also working on generating stubs of a lot of the DAO/Manager/Action files - I believe that's his automation stuff. Thanks for giving back so much to AppFuse Mike - now if I only had more time to keep up with your enhancements. ;-)

Wanna use Spring in your AppFuse-derived webapp?

Yesterday, I ported an AppFuse application (based on 1.3) to use all the latest stuff I've done in the last month. Basically, I just renamed and reorganized the directory structure, integrated Spring to bind everything together, and implemented the new Remember Me functionality. If you want to upgrade your (AppFuse-derived) webapp to use Spring, I wrote up an article on how I did it. It's quite a process, but hopefully this article will make it a lot easier. Now I can use Tomcat 5 as my primary app server (vs. Tomcat 4) - sweet!

Pro JSP gets 10 Horseshoes!

Gregg Bolinger has reviewed Pro JSP and gives it 10 horseshoes! Very nice - thanks Gregg! The book from which AppFuse was born...

AppFuse Refactorings Part IV: Replacing Hibernate with iBATIS

This is a continuing series on what I'm doing to make AppFuse a better application in Winter/Spring 2004. Previous titles include: Changing the Directory Structure, Spring Integration and Remember Me refactorings.

- - - -
On my last project, we ported an existing JSP/Servlet/JDBC app to use JSP/Struts/iBATIS. In the process, I got to learn a lot about iBATIS and grew to love the framework (although I prefer to spell it iBatis). It was super easy to port the existing JDBC-based application because all of the SQL was already written (in PreparedStatements). Don't get me wrong, I think Hibernate is the better O/R Framework of the two, but iBATIS works great for existing databases. The best part is that iBATIS is just as easy to code as Hibernate is. For example, here's how to retrieve an object with Spring/Hibernate:

And with Spring/iBATIS, it requires a similar amount of Java code:

The main difference between the two is that iBATIS uses SQL and Hibernate uses a mapping file. Here's the "getUser" mapped statement for iBATIS:

  <mapped-statement name="getUser" result-class="org.appfuse.model.User">
      SELECT * FROM app_user WHERE username=#username#;
  </mapped-statement>

Spring makes it super easy to configure your DAOs to use either Hibernate or iBATIS. For Hibernate DAOs, you can simply extend HibernateDaoSupport and for iBATIS DAOs you can extend SqlMapDaoSupport.

Now to the point of this post: How I replaced Hibernate with iBATIS. The first thing I had to do was write the XML/SQL mapping files for iBATIS. This was actually the hardest part - once I got the SQL statements right, everything worked. One major difference between iBATIS and Hibernate was I had to manually fetch children and manually create primary keys. For primary key generation, I took a very simple approach: doing a max(id) on the table's id and then adding 1. I suppose I could also use the RandomGUID generator - but I prefer Longs for primary keys. Hibernate is pretty slick because it allows easy mapping to children and built-in generation of primary keys. The ability to generate the mapping file with XDoclet is also a huge plus.

As far as integrating iBATIS into AppFuse, I created an installer in contrib/ibatis. If you navigate to this directory (from the command line), you can execute any of the following targets with Ant. It might not be the most robust installer (it'll create duplicates if run twice), but it seems to work good enough.

                install: installs iBatis into AppFuse
              uninstall: uninstalls iBatis from AppFuse
    uninstall-hibernate: uninstalls Hibernate from AppFuse

                   help: Print this help text.

All of these targets simply parse lib.properties, build.xml and properties.xml to add/delete iBATIS stuff or delete Hibernate stuff. They also install/remove JARs and source .java and .sql files. If you're going to run this installer, I recommend running "ant install uninstall-hibernate". Of course, you can also simply "install" it and then change the dao.type in properties.xml. This will allow you to use both Hibernate and iBATIS DAOs side-by-side. To use both Hibernate and iBATIS in an application, you could create an applicationContext-hibatis.xml file in src/dao/org/appfuse/persistence and change the dao.type to be hibatis (like that nickname ;-). In this file, you'd have to then define your transactionManager and sqlMap/sessionFactory. I tested this and it works pretty slick. Click here to see my applicationContext-hibatis.xml file.

<!-- Hibernate SessionFactory -->
<bean id="sessionFactory"
  class="org.springframework.orm.hibernate.LocalSessionFactoryBean">
  <property name="dataSource"><ref local="dataSource"/></property>
  <property name="mappingResources">
    <list>
      <value>org/appfuse/model/Role.hbm.xml</value>
      <value>org/appfuse/model/User.hbm.xml</value>
      <value>org/appfuse/model/UserCookie.hbm.xml</value>
      <value>org/appfuse/model/UserRole.hbm.xml</value>
    </list>
  </property>
  <property name="hibernateProperties">
    <props>
      <prop key="hibernate.dialect">@HIBERNATE-DIALECT@</prop>
    </props>
  </property>
</bean>

<!-- SqlMap setup for iBATIS Database Layer -->
<bean id="sqlMap" class="org.springframework.orm.ibatis.SqlMapFactoryBean">
  <property name="configLocation">
    <value>classpath:/org/appfuse/persistence/ibatis/sql-map-config.xml</value>
  </property>
</bean>

<!-- Transaction manager for a single JDBC DataSource -->
<bean id="transactionManager"
  class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
  <property name="dataSource"><ref local="dataSource"/></property>
</bean>

<!-- LookupDAO: iBatis implementation -->
<bean id="lookupDAO" class="org.appfuse.persistence.ibatis.LookupDAOiBatis">
  <property name="dataSource"><ref local="dataSource"/></property>
  <property name="sqlMap"><ref local="sqlMap"/></property>
</bean>

<!-- UserDAO: Hibernate implementation -->
<bean id="userDAO" class="org.appfuse.persistence.hibernate.UserDAOHibernate">
  <property name="sessionFactory"><ref local="sessionFactory"/></property>
</bean>

Some things I noticed in the process of developing this:

• Running "ant clean test-dao" with iBATIS (28 seconds) is a bit faster than Hibernate (33 seconds). I'm sure if I optimized Hibernate, I could make these numbers equal.
• The iBATIS install is about 500K, whereas Hibernate's JARs are around 2 MB. So using iBATIS will get you a slightly faster and smaller AppFuse application, but it's a bit harder to manipulate the database on the fly. There's no way of generating the tables/columns with iBATIS. Instead it uses a table creation script - so if you add new persistent objects, you'll have to manually edit the table creation SQL.

Hibernate is still the right decision for me, but it's cool that iBATIS is an option. Even cooler is the fact that you can mix and match Hibernate and iBATIS DAOs.

Tapestry looks very nice

While leaving a comment on my ActionForms: Struts' bastard child post, Erik Hatcher sounds like a broken record:

> When are you going to just quit asking questions and try out Tapestry? 
> You can build it from CVS HEAD easily or just grab a 3.0 binary (currently 
> beta, but way stable). Drop in the WorkBench WAR file and see for yourself.

So I took 5 minutes and downloaded and deployed the WorkBench WAR. Check it out if you like. Looks pretty nice to me. The DatePicker is pretty cool, but it shows up in the wrong spot on Firefox - and it's annoying that I can't close it just by clicking on the screen somewhere (like most popup calendars). Also the Chart doesn't work on my Linux box (it worked fine on Windows).

However, if you're looking for something like the DisplayTag, Tapesty has that. The URLs it constructs for everything look a little ridiculous though. I wonder if a Filter with smarts could pretty those up?

AppFuse Refactorings Part II: Spring Integration

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:

This way, the UserManager implementation can be easier retrieved using:

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.

How much CPU Power does a Java/Tomcat app need?

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.

ActionForms: Struts' bastard child

Folks that rag on Struts seem to point to ActionForms as one of its major design flaws. I've been slightly frustrated with ActionForms this week, but overall, I think they're a good thing. It's possible my ActionForm affection is misguided. The major reasons I like them is because I believe they allow me to do stuff that is not possible in other web frameworks. I definitely could be wrong though, so I'm hoping the other framework authors/users will speak up and say "My framework does that!" Specifically, I'm talking to the WebWork, Tapestry, JSF and Spring folks.

I do wish that I could throw my POJOs up to my UI, so I hope the following things are possible with the WTJS frameworks. It would simplify things if I didn't need to transform POJOs -> ActionForms (particularly with Hibernate).

• Validation and re-displaying the user's entered values. I love Struts' Validator. It's great how I can generate the validation.xml file with XDoclet and have a "required" struts.validator tag right next to a hibernate not-null="true" tag. Two questions:
  
  1. Can any of the WTJS frameworks re-display the user's entered values? Specifically, back into the input fields where the user entered them? I think this is important for useability.
  
  2. Do any of them have the ability to generate client and server-side validation, or at least declaratively write it in XML?
  
  I'd love to find a way to hack the Validator to allow you to define validation rules for a POJO and then use an Interceptor to validate it. I don't like how Spring requires you to write YAJC (Yet Another Java Class) to do validation.
• Handling checkboxes. The basic reason for the reset() method in ActionForms is to handle checkboxes. Since unchecked checkboxes don't send a value - there needs to be a way to set a boolean back to null. I'm sure all of the WTJS frameworks support checkbox handling, I just want to make sure - and frankly - I'd like to learn a little more about how each framework handles it.

I guess there's only two reasons I like ActionForms - the major one being the ability to specify (and generate) my client and server-side validation in XML. If I don't find this same slick feature in the other frameworks, I might have to do a bit of hacking to do the Interceptor with Validator thing - but hopefully I won't need to go there.

AppFuse Refactorings Part I: Changing directory structure

I changed the directory structure of AppFuse's "src" and "test" directories this weekend. Rather than:

src 
  - common
  - ejb
  - web

I changed it to:

src
  - dao
  - service
  - web

The change wasn't too difficult, but the results of doing it make me a bit sick to my stomach. I always new that the Managers in AppFuse were dependent on Struts, that's why I originally put them in the src/web/**/webapp/service folder. Now that I've moved them into the service folder, they don't inherit all the luxuries like struts.jar being in the classpath. Even worse, to compile the Managers, I have to compile any ActionForms, both from the build/web/gen directory, as well as from src/web/**/Form. This is because the Managers use BeanUtils.copyProperties() to transfer values from POJOs -> ActionForms and visa-versa.

Ech - this exercise has really shown me how tied together the different directories and layers are. I think I liked it better the other way - or maybe I just liked not knowing how tightly integrated everything was. ;-) The most frustrating thing turned out to be that Ant's <javac> task wanted to re-compile the generated ActionForm's each time I I ran "ant compile-service". Adding an <uptodate> property fixed this problem, but it seems like it should be easier than that.

I ended up putting the org.appfuse.model package in the "dao" directory. It just made things easier - since the model.* classes are used in my DAOs and the "test-dao" needs the XDoclet-generating Hibernate mapping files. I didn't want to have to depend on classes in the src/service directory to compile src/dao. It's bad enough I have to do that with the service-web stuff.

All in all, I'm happy with the refactorings, but implementing workarounds for the service-web relationship was no fun. I probably did this when I originally created AppFuse, but since I haven't heavily manipulated build.xml in so long - I've forgotten the trouble I went through.

Oh yeah, I also integrated Spring for binding the layers and configuring Hibernate. And Charles' persistent cookie strategy? That's done too. I'll write up details on both of these refactorings in the next couple of days.

One big Service class or several small classes?

I asked this question on the Spring Forums a couple of days ago, but I didn't get a response, so I'll try it here.

Looking through the Spring's petclinic and jpestore applications - both seem to advocate one single class to interface with the database (hibernate or dao/ibatis). I also noticed this pattern in Java Open Source Programming. Is this a recommended pattern or do you still think there's value in several service-level classes (i.e. one for each DAO)? I imagine the single interface and impl could grow quite large on a big project. In fact, in the Spring examples, the Manager isn't even a Business Delegate, it's really a Persistence Manager.

BTW, the Petclinic app is a helluva plug for Hibernate. The Hibernate implementation class is 53 lines, and the JDBC implementation class is 770 lines! If you're still using JDBC over Hibernate, please explain why you put yourself through the pain?

I do like the simplicity of the Single Manager approach, but I tend to do 1 Manager for each DAO (or something resembling this pattern). What do you advocate? AppFuse follows the 1-Manager to 1-DAO pattern. Should I switch to the Single Manager pattern?