Raible Designs

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.

Tomcat's Ant Tasks

Since I hold the top 3 spots on Google for Tomcat's Ant Tasks, I figured it was about time I figured out how to use them. So I did - you can read the How-To on my wiki. They're pretty slick now that I have them working. The real power (as I see it) is that ability to install a WAR on a server other than localhost. Does your appserver have Ant tasks to ease your deployment headaches? If so, I'd like to hear about them.

I also upgraded to DBUnit 2.0 and JSTL 1.0.5 today. They seem to be good releases - all my tests run without errors.

Ant 1.6.0 with Canoo's WebTest and AppFuse

If you want to use Ant 1.6 with Canoo's WebTest, you'll need to patch the source. Many thanks to Paul Kavanagh for providing the patch - I hate it when I can't upgrade to the latest release. Since AppFuse relies on WebTest for running its JSP tests, you must patch webtest to use Ant 1.6. Or you can can just download webtest.jar and put it in your lib/webtest*/lib directory. This is the from the latest version of WebTest's CVS (build 379 is the latest release used in AppFuse).

What's new in Tomcat 5

Want to know what's different between Tomcat 4 and Tomcat 5? If so, you should check out this article. I haven't read it (yet), but I hope to soon. Today, I was planning on working from home, plowing through my stuffed head and headache with the power of DayQuil. However, Julie had to run into work (she stayed home with Abbie yesterday, who is also sick). So Abbie and I are going to be sickos together all morning. The problem is that Abbie doesn't know she's sick - she's still happy as a pig in sh*t and wrecking the place. I'd better go and stop her...

Oh wait - Telletubbies just came on - she's mesmerized, that gives me a half hour. I'd love to work on AppFuse, there's never been more stuff I'd like to integrate. Here's a list of stuff waiting for SF's CVS to get it's act together:

• Start integrating Spring.
• Various bug fixes as reported by users.
• Charles' persistent cookie strategy.
• WebTest patch to work with Ant 1.6.0.
• Figure out how to run AppFuse on JBoss - thanks to Rick Hightower and Brian Topping (on the roller-user mailing list) this should be pretty easy.
• Figure out how to run AppFuse on Orion - I got an e-mail yesterday with some hints, so this shouldn't be too hard either.

As far as SourceForge's CVS, if you were to checkout AppFuse right now, you'd get the latest code, but you'd also get a bunch of files I deleted ages ago. I submitted a bug - here is the response I received:

This issue (file present both Attic and non-Attic) would have been caused by a file removal between the time of our full repository sync and the update sync; or by outdated data being present after our initial sync (due to a sync bug) -- both possible cases with our recent systems upgrade. We are presently in the process of generating a list of such duplicates (using a set of scripts we wrote) and will perform a clean-up of this issue once the script run completes. Additional information will be posted to this request no later than 2004-01-30. Your patience is appreciated.

Back to babysitting, Abbie's getting bored with Telletubbies.

A few thoughts on AppFuse

I've been thinking about how to structure AppFuse for the upcoming Spring and iBatis enhancements. These enhancements shouldn't require any directory structure changes. However, I've received some suggestions to change the common, ejb and web directory structure to be a little more inline with the tiers. So it would become something more like database, business and web (or dao, service and web). After thinking about this for the last couple of days, it seems to make sense. I picked up the notion of common from Erik Hatcher's JavaDevWithAnt, which I borrowed heavily from when creating AppFuse. Erik used common because this represented classes that would be included in both the web tier and the EJB tier. But since I (currently) don't plan on every adding EJBs to AppFuse, does it make sense? Even if I did, I'd probably only use SessionBeans, and those could easily fit into the service layer. The nice thing about moving the business layer (currently in web/**/services) to it's own directory is that it will get it's own JAR (with hardly any modifications to build.xml) and can be used outside of the webapp.

The nice thing about isolating the web directory to web-only classes is I can use Ant to replace any Struts-specific classes with WebWork or Tapestry. To prevent AppFuse from being cluttered with too many options, it'll ship with Struts out-of-the-box. If users want WebWork for their framework, they can download a WebWork version of the web-tier and run an Ant target that will replace all the Struts stuff with WebWorks stuff. It seems like the cleanest way to do web framework switching.

Another thing that might happen to AppFuse, caused by my enthusiasm to try out everything, is that it will contain too much stuff for a basic web application. It currently has security and user management built in, which is what most webapps need. I recently added in OSCache and Clickstream. OSCache is not enabled, but most webapps can probably use it somewhere. Clickstream is a different story. For most of the webapps I've built, this is not needed at all. Most of the apps are no more than 20 screens, and it's unlikely the client will care where people go the most. Another option that deserves ripping out is the idea of Struts' submodules. I tend to rip this out as the first thing when starting a new project. File Upload is something I've used rarely, so I should probably lose that feature too.

There are also other technologies that I've thought of adding to AppFuse, namely Quartz and Lucene. However, I've only used Quartz on 1 of my last 5 projects and Lucene on 2 - so obviously these might be considered bloat for a basic webapp. I think the best thing would be to implement these in AppFuse, on my own, and then document how I did it on the wiki (for an example, see diagramming build.xml with Vizant). If folks need to use it they can add it on their own. Documentation is always good, and if I can just document how to add stuff, I can certainly reduce the bloat.

Whaddya think - is it better to include options out-of-the-box or simply document them? Should I restructure the directories to match the tiers more?

Tomcat 5.0.18 Released

Download or read the Release Notes. You know what bugs me about this release? The release notes suck! There's no changelog - what bugs got fixed, which ones didn't? Any new features? I suppose I could go crawling around their bug tracker and find out, but isn't this the kind of information you'd like to see with the release? Should I upgrade? Why should I upgrade - is something broke in 5.0.16 that's fixed in 5.0.18? Are there memory leaks that got fixed?

The only reason I develop on 4.1.29 these days is because my Remember Me feature works on 4.1.x, but not on 5.0.x. I could make it work on 5.0.x, but it wouldn't be as secure. I hope to implement Charles' recommended cookie strategy and then go for 5.0.x as my development platform, but that'll be a few more days.

On another note, I've implemented the Tomcat Ant tasks in AppFuse and I must say, these things are nice. The main advantage is speed, which all developers love.

Can your laptop do this?

Another reason why PowerBooks rule: I starting running "ant test-all" right before I left for the office this morning. I closed the lid as it was starting Tomcat to run Cactus tests. When I got to the office, I opened the lid, and Tomcat continued starting and all the tests finished running. Can your laptop do that?

AppFuse vs. Spring

I received an interesting e-mail this morning. The writer said his team is comparing AppFuse and Spring in terms of kick starting a project. This struck me as odd, especially since these two applications are quite different. Here's my response:

I think AppFuse and Spring are two completely different animals. IMO, Spring is excellent for wiring components together (i.e. Interfaces and Implementations) as well as simplifying J2EE's APIs. Of course, it has its own web framework too, but it also integrates nicely with Struts, WebWork and Tapestry. AppFuse is designed to be an application that helps you get *up and running* with your J2EE web application in the minimal amount of time. Its power is in the directory structure, Ant integration (build.xml) and testability. Also, XDoclet is heavily leveraged for code generation and maximizing developer's productivity. In essence, it's really just a packaging of other open source projects, including: Ant, XDoclet, Hibernate, JUnit, Cactus, StrutsTestCase, Canoo's WebTest, Struts Menu, Display Tag Library, JSTL and Struts (including Validator and Tiles). But rather than just packaging these together, it's also got Security and User Management built-in and contains tutorials on how to develop and test the different layers.

Here are some links on integrating Spring with other Java-based web frameworks:

Struts: http://struts.sourceforge.net/struts-spring/
WebWork: http://wiki.opensymphony.com/space/Spring+Framework+Integration
Tapestry: http://www.springframework.org/docs/integration/tapestry.html

And here are a couple of good simple descriptions of Spring:

http://test.javaranch.com/wiki/view?SpringFramework
http://barracudamvc.org/lists/archives/barracuda/2003-December/007156.html

I do plan on integrating Spring into AppFuse in the next release - so it might be awhile until I release 1.4. I basically plan on using it to wire my Managers together, as well as my DAOs. Currently, I don't think I'll use its web framework, but who knows. In the latter half of this year, I hope to add support for WebWork and Tapestry as web frameworks.

RE: AppFuse (Getting started with...)

Rick Hightower has started using AppFuse. It looks like he had a couple of issues, so I figured I'd post some solutions here for all to see (also because typing in comments w/o HTML on JRoller sucks).

Rick - I don't know why you're getting the first error with CATALINA_HOME. I just tried removing that as an environment variable on my PowerBook and I'm able to run "ant setup-db" just fine. If you've setup the MySQL database with the default settings, you should end up with a "root" user and a blank password. These settings are both specified in properties.xml, where database.admin.username=root and database.admin.username=(nothing). Of course, you can change these properties values by editing properties.xml, or by specifying them in your build.properties file. From the following error on your site:

db-load:

BUILD FAILED
C:\source\appfuse\build.xml:931: java.sql.SQLException: Invalid authorization sp
ecification,  message from server: "Access denied for user: 'rick@localhost' (Us
ing password: YES)"

It looks like you have an administrator named "rick", but that your password was incorrect. YES is not the password you provided - that's just MySQL saying that you did provide a password.

The database creation script is at metadata/sql/mysql-create.sql and it simply creates an "appfuse" database and gives a user named "test" access to it.

create database if not exists appfuse;
grant all privileges on appfuse.* to test@"%" identified by "test";
grant all privileges on appfuse.* to test@localhost identified by "test";

The next error about j2ee.jar should be self explanatory and it looks like you figured that one out. I wish I didn't have to include the entire j2ee.jar in the classpath, but XDoclet requires javax.ejb.* JARs be in the classpath for generating Struts ActionForms from POJOs.

The last thing you did - ant -Dapp.name=sampleApp -Ddb.name=database - was to merely run the "package-web" target. It's the default target in build.xml. It simply compiles everything and packages into an appfuse-1.3.war file. In this scenario, the app.name and db.name mean nothing. If you want to create a new AppFuse project, you need to specify the new target. This will create a new project.

foxxy:~/dev/appfuse mraible$ ant new -Dapp.name=test -Ddb.name=test
Buildfile: build.xml

clean:
     [echo] Cleaning build and distribution directories
   [delete] Deleting directory /Users/mraible/workspace/appfuse/build
   [delete] Deleting directory /Users/mraible/workspace/appfuse/dist
   [delete] Deleting: /Users/mraible/workspace/appfuse/database.properties

new:
     [echo] Creating new application named 'test'...
     [copy] Copying 318 files to /Users/mraible/workspace/test
     [copy] Copying 1 file to /Users/mraible/workspace/test

BUILD SUCCESSFUL
Total time: 21 seconds

I just tried this, followed by the commands specified below and all seems to be working just fine (BUILD SUCCESSFUL - Total time: 5 minutes 13 seconds).

cd ../test
ant setup-db
ant setup-tomcat
ant test-all

Just to be clear, here's a breakdown of what the above targets do:

• setup-db: creates a database for the project, assigns users, creates all the tables and populates it with test data.
• setup-tomcat: copies a context.xml file to $CATALINA_HOME/webapps and copies the database driver to CATALINA_HOME/common/lib.
• test-all: runs all the tests to verify the functionality of the app. These include test-ejb for the DAO layer, test-canoo for all the JSPs and test-web for all the StrutsTestCase/Cactus tests and business layer tests (*ManagerTest).

The first steps after creating a new AppFuse project are probably to rename the packages to fit your company's naming convention - i.e. org.appfuse -> com.company.appname. In Eclipse (and propably IDEA), this is fairly easy. Just make sure to do it in the "src" and "test" directories, as well as search for it - it might be specified in a few XML files (i.e. hibernate.cfg.xml). You'll also need to modify the "javadoc" target to ensure that it looks for the write package names. Currently, it's set to "org.*".

Hope this helps!

AppFuse 1.3 Released!

This release fixes a few compatibility issues with Resin and other databases - specifically PostgreSQL and DB2. The major new functionality in this release is Easy Database Switching. Basically, you can very easily switch from using MySQL to PostgreSQL by only changing a few properties in your build.properties. I implemented this on my current project last week because I do most of my development (at the client) on a PowerBook. The client wants to deploy onto a DB2 database - and there is not DB2 install for the Mac. Since Hibernate allows you to easily switch between databases, I figured I could develop using MySQL on the Mac, but have the default (CVS version) use DB2. One of the things I didn't want to do was to have a build.properties.sample, because I love projects that "just work" when you type "ant". So I changed the the build process so that database.properties is generated from default settings (MySQL) or the settings in build.properties (if specified). As part of the build process, Ant looks for the following build.properties files:

• ${user.home}/.${ant.project.name}-build.properties
• ${user.home}/.build.properties
• build.properties

What this allows you to do is to take your customized database settings and put them in ~/.build.properties and they'll be applied to any AppFuse-derived project. This makes it easy to keep the CVS version of your project tied to one database and a developer's local version tied to a different database.

While it's true that you'll most likely only talk to one database during the duration of your project, this exercise proves that it's easy to migrate from MySQL to another database. It also proves that AppFuse can easily integrate with other database (at least as of this release). Slick stuff IMO.

• Download (~12.1 MB for src, ~4.3 MB for bin)
• Release Notes

One of the best parts about developing AppFuse is that it's not a library. As a developer, I don't really have to concern myself with backwards compatibility. This means that new functionality can be added quickly and easily and old stuff can be ripped out. It's too bad all OS "products" can be this easy.

What about AppFuse's future? Check out the AppFuse Roadmap to see what I'm thinking about.