Raible Designs

JDOM 1.0?

It looks like JDOM 1.0 might finally be released next month. The main motivation for this release after 10 betas? According to Jason, it's all about saving face:

As we got closer to the four year mark, JDOM began to be my own problem again. It wasn't that I had different use cases, I just didn't want to be the guy who never finished JDOM. There's nothing like a little face saving as a motivating factor.

Personally, I don't use JDOM, but I've heard good things about it.

Write your Java apps in Visual Studio.NET?

Apparently Visual MainWin allows you to write your webapps in C# and .NET and then deploy them to a J2EE server.

Visual MainWin for J2EE enables these organizations to deploy .NET and J2EE applications on a single J2EE infrastructure, eliminating the need to maintain two separate application servers or implement complex interoperability solutions between the .NET and J2EE platforms.

This product certainly won't do anything for me. I've heard that Visual Studio is a great IDE, but if I can't write Java in it - what's the point?

Then again, I'm biased. I have a friend who is a long-time Java developer. Lately, he's been developing in C# because that was the only gig he could get (in Nevada). He says that C# is a piece of sh*t compared to Java.

Update: My friend contacted me to set the record straight. To quote him, "C# is OK, its the .NET framework that sucks ass. The C# syntax is a total ripoff of Java anyways."

Good Ant Tip

Nick has an Ant tip that I can put to good use.

This A little-known Ant feature is the hyphenated target name. If you have a target name that starts with a "-", such as "-test-setup", you will not be able to call that target from the command line. Developers creating utility targets in their build.xml files can use this to avoid confusing other developers with irrelevant support targets.

There are a fair amount of internal targets in AppFuse that don't need to be visible and can't be really be called from the command line. Last time I checked, IDEA and Eclipse both allowed hiding of internal targets - so I rarely see these, but it might be a good idea to make them more explicit. I'll put it on my what-I-can-do-when-I-get-bored list.

Fast Company's Fast 50

Via Erik, Six Apart makes Fast Company 50. Personally, I don't give a rat's ass about Six Apart, but I do think it's cool that Chipotle made the list. The first Chipotle is right next to DU on Evans and we currently live a mere 6 blocks away from it. In fact, I was just telling Abbie how good it is when we walked by it this evening.

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.

AppFuse Refactorings Part III: Remember Me

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 and Spring Integration.

- - - -
AppFuse includes a Remember Me feature that works with Container-Managed Authentication. In version 1.3 it works by setting a few cookies: username, password and rememberMe. The last one being a simple flag that the user wants to be remembered. Then a LoginFilter checks for the rememberMe cookie, and if present, logs in the user using the other cookie values. The obvious issue with this is that the password being sent and stored on the user's browser.

This was easily solved in Tomcat 4 by placing the form-login-page and form-error-page under a "security" directory and then setting cookies on the /appfuse/security path. This way, since no other part of the app can access /appfuse/security, these cookies can never be retrieved in any part of the application. The problem is that this didn't work in Tomcat 5 since it forwards to the login page (rather than redirecting). Since forwarding is obviously a better solution (user's can't bookmark the login page), I needed a new way to implement the Remember Me feature.

To my knowledge, cookies can only be stolen if someone is able to login to your AppFuse app and insert JavaScript to send the "document.cookie" value to an external URL. So for AppFuse, it's likely that stealing cookies is not much of an issue. However, for applications like Roller, it is an issue - since other bloggers on the same server (i.e. JRoller) could put JavaScript on their blog to grab cookies from other users.

Just as I was about to give up searching for solutions, along came Charle's persistent cookie strategy. Here's how I implemented it in AppFuse. Hopefully it follows all the rules and is a good solution. Here's what I did make it happen.

- - - -
Step 1: Setting the cookie.
Scenario: A user logs in and selects the "Remember Me" checkbox.
What Happens: When a user clicks the Login button, they submit to a LoginServlet that redirects them to "j_security_check" to take advantage of Container-Managed Authentication. This servlet is responsible for ensuring an SSL Login (if enabled), encrypting the user's password (if enabled) and also sets a session variable to indicate the user wants to be remembered. After authenticating, the user will hit the ActionFilter, where the following code sits:

In the above code snippet, the UserManager.createLoginCookie(username) method is responsible for creating a new cookie string and storing this information in the database.

The RandomGUID is a class I found on Java Exchange. Once the rememberMe cookie was set, I had to configure LoginFilter.java (mapped to form-login-page and form-error-page) to look for this cookie. This brings us to Step 2.

- - - -
Step 2: Using the cookie to login the user.
Scenario: A User has already logged in successfully with "Remember Me" enabled.
What Happens: When the login page is served up to the user, the LoginFilter is invoked and it checks the validity of the "Remember Me" cookie.

The UserManager.checkLoginCookie(value) method looks up a record based on the random GUID, and if it finds a match, it creates a new GUID and saves it in the database. If null is returned, it means the cookieId doesn't exist, and the login proceeds as it normally would. Below is the guts of the checkLoginCookie() method.

You can see from this, that if the lookup succeeds - a new cookieId is saved and returned. If a not-null cookieId is returned, the remember me cookie is updated, the user is looked up and the Filter forwards an authentication request (with username/password) to the LoginServlet. The Filter also sets an attribute to let the application know that this user authenticated via cookies. This is important so that cookie-authenticated users cannot change passwords. When using cookie-authentication, the password field is hidden and a message warns the user that they must logout/login to change passwords.

Lastly, I had to come up with a solution to remove these login cookies.

- - - -
Step 3: Allow the user to clear their login cookies.
Scenario: A User has already logged in successfully with "Remember Me" enabled.
What Happens: For this, I implemented a simple solution. When a user logs out, all persistent login cookies are removed.

I don't know if it's best to divulge the details of AppFuse's cookie login strategy. However - it *is* open source - so folks can find figure it out if they really want to. By exposing it to the world, I hope to get the most robust solution possible.

Next up, how I replaced Hibernate with iBatis. Using Spring, it only took me a few hours! Pretty slick, eh? ;-)

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.

Approved for Google Ads

After seeing that Tim Bray is making $500/month of Google Ads, I decided it was high time I try to get this site approved again. Low and behold it worked! So they've approved me, but I only want to show them when folks come from Google. As in, when the referer (yeah, I know that's spelled wrong, but it is in Java and JavaScript too) contains "google" - show the ads. Anyone know how to do this cleanly in Roller/Velocity? Or JavaScript? I tried the following, but it doesn't work:

if (document.referer != null 
    && document.referer.toString().indexOf("google") != -1) {
    // define variables
    document.write("<scr" + "ipt type='text/javascript' src='ads.js'><\/scr" + "ipt>");
}

Since Google is my top referrer - I think I'll get a fair amount of users seeing the ads, and it won't disturb the folks who come here just to read my ramblings.

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.