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.

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?

[Review] Java Open Source Programming

Today I finished reading Java Open Source Programming. It took me one week to read - and I only read about an hour a day. This book is nice to read - you can breeze through 20 pages in no time. I appreciate a quick-read technical book. I enjoyed the simplicity of this book, especially since I'm such a rookie at WebWork, SiteMesh and Mock Objects. I knew most of the Hibernate and XDoclet stuff, but I did manage to pick up a few tricks, and since it's the only book on Hibernate (that I know of), I'll refer to it when I need to do components or proxies. Overall, this book made WebWork and SiteMesh look like great technologies and I'm excited to start using them.

The sample app, PetSoar, continues the "call your persistence layer from your action class" that I've seen in all WebWork sample apps. I still don't know if this is a good idea, but since Actions aren't tied to the web, maybe it is. This means you put your business logic in your controllers (a.k.a. actions). Kinda breaks the whole controllers should only be controllers mantra, but whatever floats your boat. To be honest, in AppFuse, all the Managers (a.k.a. business layer) do is transfer POJOs to ActionForms, and then back again. The Managers are were my business logic should go, but I often find it easier to put it in my actions. I sense a paradigm shift - will the WebWork version of AppFuse only contain a "dao" layer and a "web" layer? Who knows - only time will tell.

One interesting thing I picked up is the different way that Dependency Injection (a.k.a. Inversion of Control) is handled in WebWork compared to how its handled in Spring. In Spring, all you need to do is add a setter (and local variable) to prepare a class for IoC. When using WebWork, you have to create an Interface that has the setter defined, and then your Action must implement that interface. If Spring can do it without an interface, why can't WebWork?

All in all, I enjoyed this book - though it didn't peak my interest as much as J2EE Design and Development. I think that's probably because Spring solves some issues I've had with AppFuse (binding interfaces and implementations), whereas this book doesn't really solve anything for me. As a WebWork newbie though, I do feel this is a good read. I also found myself saying "Wow, that's cool" a fair amount of times (re: SiteMesh and WebWork).

I was disappointed that i18n was not covered at all. I tend to always prepare my Struts apps for i18n (extracting text into a .properties file). However, in most cases, a 2nd translation has never been put in place. So, I bitch about the lack of i18n coverage, and I write my apps with i18n in mind, but it's never been used in any of the apps I've written. Maybe I should just quit doing i18n in my apps - it'd probably save an hour a week of development time.

So it comes down to this - if you don't know anything about WebWork, this book is a worthwhile read. If you know WebWork - I'm sure you'll be disappointed because it is written for newbies.

Next up, upgrading my programmer certification to 1.4 with the Sun Certified Programmer & Developer for Java 2 Study Guide.

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.

Turn off sessions in your JSPs

One of the tips I picked up in J2EE Design and Development was to turn off automatic session-creation in your JSPs. So I tried this today on my project, and it doesn't seem to work. Basically this involved putting the following at the top of your JSPs:

<%@ page session="false"%>

I did this by adding this to my taglibs.jsp, which is included in every other JSP - so it should affect all my JSPs and prevent a session from being created on my welcome-file - right? Not according to Tomcat's Manager application - it still increments the number of sessions as I hit the welcome page with different browsers. Am I doing something wrong?

I'd love to get this working - so sessions are only created when a user logs in. Those JSPs that need a session, I'll override the default with session="true". I often see a whole bunch of sessions on the wiki and roller apps on this site - and in reality - a session should never be created, unless I login. At least I think that's how this is designed to work...

Velocity's DataSourceResourceLoader

In the current project I'm on, one of the major requirements is to have the ability to send job postings to job boards such as Monster.com, CareerBuilder.com, etc. - as well as local newspapers. When I first started this project, I went about contacting all of these advertisers and explained that we'd like to automate the process of talking to their system. I found that many of them preferred a simple e-mail with the job posting, but others wanted us to FTP a pre-formatted document to them.

I figure the easiest way to handle this is to use Velocity. By using Velocity, and storing templates in the database, users of the system can either (1) use a default template or (2) customize a template for a specific advertiser. This was all easy enough since we're using Struts Resume as a baseline for this project, and Velocity is already built-in.

I remembered seeing that Velocity had some sort of database ResourceLoader, so I went searching and found the DataSourceResourceLoader:

This loader will load resources from a DataSource such as a database. This loader is not built as part of the standard build as it requires J2EE support. To build this loader, please download the J2EE distribution, move the j2ee.jar into the build/lib directory, and then build the new velocity jar with the jar-j2ee build target. For more information on this loader, please see the javadoc for DataSourceResourceLoader.

After checking out Velocity 1.4.1 RC1 (are they ever going to release this thing?) from CVS, I was able to build a new Velocity JAR. To compile using J2EE 1.4, you have to modify the VelocityServletTest, or delete it. I then replaced velocity-1.4-rc1.jar with this new JAR (which is actually 4KB smaller), configured velocity.properties and Voila - it worked! Clean and easy integration - just the way I like it.

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!

[ANNOUNCE] Resin 3.0.5 Released!

View the Release Notes and Download. A couple of the bugs I found when running AppFuse on Resin have been fixed: <description> is now a valid property of <user-data-constraint> and the following JSTL statement should work as well.

<fmt:message key="login.signup">
    <fmt:param><c:url value="/signup.jsp"/></fmt:param>
</fmt:message>

DJUG Meeting: The Future is Swing

I attended the Denver JUG meeting tonight and definitely enjoyed myself. It helped that I got to see an old friend, but it was also a nice refresher on XSL-FO and a great overview on J2EE UI choices. The basic concepts meeting was on XSL-FO, which as far as I know, is mainly used for creating PDF documents from XML content. Apache's FOP is widely used for doing XSL-FO in Java.

So here's a question for you - if I want to produce PDF versions of my resume (in struts-resume), which technology should I use? I know it'd be fairly easy with XSL-FO, but what about JasperReports? I'd like an easy way for users to be able to upload new "templates" for the PDF version of their resume, so FO might be the way to go. In addition, I'd also like to implement the PDF-rendering technology that I'll likely use on a real-world project. Are there some good APIs to use?

I did some XSL-FO work a couple of years ago and it seemed pretty cool, but it required a lot of trial and error to get things looking right (as is the case with most XSL). My favorite tool at the time was RTF2FO, which allows you to create a Word document with the look you want, save it as an RTF, and then convert it to a FO (.fo) document. Pretty slick stuff - it looks like they have a free trial and it's only $50/machine. The project I used it on was only 3 weeks, so the trail version did me just fine.

The main presentation was delivered by David Curry, who seemed to be an expert on J2EE UI choices.

David Curry is Director of Systems Development for ADP/SIS, part of the ADP Brokerage Services Group. He and his team use J2EE with DHTML, XML and Swing to develop mission-critical desktop productivity applications for brokerage and bond trading firms.

The main thing that impressed me was that David has been developing the same application since 1992. The app started out as a PowerBuilder desktop app, and moved to an HTML app, then DHTML - and now they're moving to Swing. They recently chose Swing (with the help of JGoodies) over their DHTML interface because 1) Java Web Start makes it much easier to deploy and 2) it's much more responsive for users on dial-up connections. David mentioned that it's a good idea to break your app into many separate jars so users don't need to update the entire app for new releases (a.k.a. JNLP Versioning).

I've often argued that you can make a webapp do almost anything a desktop app can do, but I can't argue with the bandwidth thing. It does take a long time to download a webapp that has a lot of JavaScript, CSS and images that make it rich. David mentioned that Gartner expects HTML interfaces to subside in the coming years, and for rich UIs (like Swing and SWT) to become more the norm. In one sense, I hope they don't - the only reason I'm in this industry is because of my HTML/CSS/JavaScript skills. It's all I know. Sure, I could probably learn Swing, and I might even like it, but I'd rather not. Learning Spring, WebWork and Tapestry sounds like more fun. Of course, if they can support a Swing UI, then I've lost nothing by learning them. I know WebWork does, but what about Tapestry? Is it view-technology-agnostic?

On the other hand, Swing does have some advantages:

• There aren't as many choices. Desktop apps are desktop apps, they should look like them. A lot of webapp developers (including myself) can get caught up in making a webapp look like a great website. The web offers so many more choices for look-n-feel that it's hard to decide which is right. I spend more time tweaking UI code (JavaScript and CSS) than doing anything else.
• Java Developers can develop the UI. In my experience, I have a rare set of skills - a strong HTML/CSS/JavaScript background, and a firm grasp of Java. The industry rumor is that there's HTML developers and Java Developers, but they're rarely the same person. David mentioned that there team is nicely consolidated to 6 developers - and everyone knows how to program in all layers. This sounds like smart management to me, moreso than Swing makes your team more efficient.

The other side of the coin is that Swing will never replace many webapps. For instance, it could never replace Roller. Why would readers want to download a Java app to read this site. However, since most of you probably use client-side aggregators and client-side editors, maybe the shift to desktop apps has already started...