Raible Designs

Should I change AppFuse's default web framework?

Currently, the default web framework in AppFuse is Struts. It's nothing fancy like Shale or Struts Ti, but rather Struts Classic. Even though Struts is not dead it's a pain in the ass to work with compared to other MVC frameworks like Spring MVC and WebWork. Yesterday, on the AppFuse Mailing List, I kicked off an informal poll about switching to a different default web framework. I think most of the people that choose Struts w/ AppFuse are choosing it b/c it's the default. Making another framework the default would likely same quite a few users a lot of headaches.

So which one should I make the default? Here's my thoughts from the mailing list thread:

I like Spring MVC and WebWork better than Struts, but I believe that WebWork is much easier to understand and develop with. Unfortunately, it's not well documented or marketed, so it's a bit difficult when you run into snags. Of course, if you contact the user community via forums or e-mail, answers flow quickly.
...
I'd like to use the framework that's simplest to understand. Right now, in my eyes, that's WebWork. I think JSF and Tapestry are excellent too (as component-based frameworks), but Tapestry's learning curve is difficult and JSF has a lot of issues (like everything is a post). Hopefully things will get better with JSF 1.2, but it's probably another 6 months before MyFaces supports 1.2 - let alone the app servers.
...
Maybe we should just drop Struts altogether - or replace it with Struts Ti? Unfortunately, it'll probably be a while before it's ready for production (I doubt it's that useable now).

Of course, if a WebWork Book was out - this move would be a lot easier. I did talk to Patrick Lightbody on IM yesterday and he said "it's done" and supposedly he has copies, but I haven't seen anything on the WebWork Blog to prove this.

A related question: how much would it hurt AppFuse if I dropped Struts altogether and went with something like Wicket instead? I'd like to keep that cap at 5 web frameworks. If I dropped Struts and added Wicket, I might lose potential users, which might not be a bad thing.

Biled Again, this time because my design sucks

Looks like I've been biled again. Unlike the last time, this time Hani doesn't offer any specifics, he merely says that my OSS efforts don't do anything other than the "very very basics".

Java, specifically, goes a long way towards ramming down a set of design principles. Said principles are followed fairly blindly by most practitioners. The OSS world is awash with examples of people who have read the right books, but have absolutely no skill or talent at conceptualising or grokking the underlying principles behind the books. To them, the design pattern is an end goal, not a tool. To pick one example (out of thousands), look at Matt Raible's OSS efforts. It has inheritance! It uses PATTERNS! It is LIGHTWEIGHT! Yet, I'd argue that it's very badly designed (if you don't believe me, just try getting it to do anything other than the very very basics.)

I'm assuming that Hani is speaking about AppFuse and Equinox, because my other efforts in OSS are minimal (Roller, Display Tag, XDoclet and Struts Menu). The reason I'm writing this post is because I'm curious to know what Hani tried to do that didn't work? Was it AppFuse/Equinox that failed? Or was it the underlying framework? Did he try to do indexed properties with WebWork or modify build.xml to deploy to Orion? Is the feature he's looking for something we can fix?

As a defense of my use of patterns, lightweight containers, etc. - it's not so much my doing that these happen to exist - they're more of a reflection on what user's want. It's a problem with Java developers in general - if you're not using patterns - users want to know why. Furthermore, most of the J2EE patterns in AppFuse are from the underlying frameworks, not from anything that I did.

As far as the design of AppFuse, I agree it could use some work. There's a lot of stuff in AppFuse that I don't use - so when I start a project with it - I usually rip out about 20-30% percent of it's features b/c I won't use them. Unfortunately, it's not that easy for others to do this b/c they don't know what they'll break if they remove a bunch of stuff. I'd like to move to a more modular, plug-in type architecture - but I have a feeling that that's the path to over-engineering. Even so, it would be pretty cool if it was possible to turn on/off features (even the use of a particular web framework) by changing a properties file.

Using Acegi Security for Remember Me and SSL Switching

I spent some time yesterday converting AppFuse's homegrown Remember Me and SSL Switching system to using Acegi Security. Thanks to Justin Spears, who provided the original motivation. It was much easier than I thought it would be, and resulted in the deleting of 7 classes in AppFuse. Not only that, but only one of them had a test for it, so the test coverage has naturally gone up as well. I'll trade 40 lines of XML for 1214 lines of Java any day - especially when I can get the support of an open-source framework.

If you're interested in using this code over 1.8.2, you can checkout the latest code from CVS (or download it from http://appfuse.org/nightly). The only other change currently in CVS is changing from "tomcat" to "user" as the default User role. Below is a list of classes that were removed as part of this move to Acegi:

• src/dao/org/appfuse/model/UserCookie.java
• src/service/org/appfuse/util/RandomGUID.java
• src/web/org/appfuse/webapp/action/LoginServlet.java
• src/web/org/appfuse/webapp/filter/LoginFilter.java
• src/web/org/appfuse/webapp/taglib/SecureTag.java
• src/web/org/appfuse/webapp/util/SslUtil.java
• test/web/org/appfuse/webapp/action/LoginServletTest.java

I should also mention that I owe a big thanks to Virtuas - who pays me to work on AppFuse these days.

Using CruiseControl with Subversion

This morning, I had the pleasure of setting up an AppFuse-based project to run under CruiseControl. Normally, this is very easy to do because I have the CruiseControl setup files and instructions. However, this project uses Subversion instead of CVS. Luckily, Subversion is easy to use and I was able to modify things to work quite easily. Below are the steps you can take to modify your AppFuse project to run under CruiseControl and Subversion.

• Download svant and extract it to your work directory.
• In build.xml, change your "cvs" target to "svn" and change the tasks appropriately.
  
  

      <path id="svn.classpath">
          <fileset dir="svnant-1.0.0-rc1/lib" includes="*.jar"/>
      </path>
          
      <taskdef resource="svntask.properties" classpathref="svn.classpath"/>
      
      <target name="svn">
          <delete dir="checkout/appfuse"/>
          <svn>
              <checkout url="https://svn.java.net/svn/appfuse/trunk" 
                  revision="HEAD" destPath="checkout/appfuse" />
          </svn>
      </target>
  

• Modify the "test" target in build.xml to depend on "svn".
• In config.xml, change the <modificationset> to be <svn LocalWorkingCopy="/home/cc/work/checkout/appfuse"/> instead of the <cvs> equivalent.

The instructions have been documented on the wiki and checked into AppFuse's CVS.

Prettying up JSPWiki's URLs

Recently, AppFuse user Charlse Li sent me an e-mail with a "PostfixURLConstructor" class designed to pretty up JSPWiki's URL. With the patch he sent, I was able to change URLs from /wiki/Wiki.jsp?page=AppFuse to /wiki/AppFuse.html. Applying the patch was quite easy, but maintaining backwards compatibility and security required a little more work. Below are the steps I went through to get everything working properly:

• Download postfixurlconstructor.zip and extract to your hard-drive. Copy the "com" directory to your wiki/WEB-INF/classes directory.
• Change the <url-pattern> of the WikiServlet in web.xml from /wiki/* to *.html.
• Add the following two lines to your WEB-INF/jspwiki.properties file:
  
  jspwiki.urlConstructor = PostfixURLConstructor
jspwiki.PostfixURLConstructor.postfix = .html

This is all you need to do to change the default URL schema. However, if you're like me and you've had a JSPWiki instance setup for awhile, you'll need to maintain backwards-compatibility. I wanted to make sure the old URLs mapped to the new ones. In addition, the "edit URL" changed from Edit.jsp?page=PageName to pageName.html?do=Edit. Since web.xml and <security-constraint> can't contain regular expressions, I used the ultra-cool UrlRewriteFilter to solve both issues. Here's the steps I went through to configure it properly:

• Download UrlRewriteFilter 2.5.1 and extract the JAR to your WEB-INF/lib directory.
• Change your web.xml to use a 2.3 DTD instead of a 2.2 DTD and add the filter and filter-mapping to web.xml.
• Create a WEB-INF/urlrewrite.xml file with the following contents:

<?xml version="1.0" encoding="utf-8"?>
<!DOCENGINE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 2.5//EN"
    "http://tuckey.org/res/dtds/urlrewrite2.5.dtd">

<urlrewrite>
    <rule>
        <from>^/Wiki.jsp\?page=(.*)$</from>
        <to type="redirect">$1.html</to>
    </rule>

    <rule>
        <from>^/(.*).html\?do=Edit$</from>
        <to type="redirect">Edit.jsp?page=$1</to>
    </rule>
</urlrewrite>

That's it - restart your server and you should be good to go. Thanks for the patch and instructions Charlse!

Update: There does seem to be a couple of issues. The 1st is that none of the attachments are resolving correctly (example). The 2nd that when I try to edit a page, it always shows up with the Main page's text. I'm not going to back out the change just yet, but I will if I can't fix it in the next several hours.

Update 2: I ended up backing out this change, but left in a forward from *.html to Wiki.jsp?page=$1 so all URLs in this post should still work. The "not being able to edit" was the major reason I rolled back to the old URL schema. The attachment issue seems to be related to my browser's cache. Clearing it fixed the problem.

Wicket is the most widely used Java Web Framework

According to this post, Wicket is the most widely used Java web framework. While I believe his statements are true, IMO it's only true in the context of this guy's post. My guess is that most of the folks that read his post were Wicket users, or somehow the Wicket Team got wind of this and told users to e-mail this guy. The main reason I don't believe that Wicket is the most popular is because it's so new. I do think it's an up and coming framework that may become the most popular, but I don't think it's there yet.

So, to answer this question, I believe that claiming Wicket to be the most widely is Just Good Guerilla PR. To put some numbers behind that, here's some graphs showing mailing list traffic for the various Java web frameworks.

Granted, these are just indicators of the number of users - but I believe they are a good indicator. One interesting note about these stats is that Wicket's mailing list traffic has increased significantly in the past few months. Ironically, here's what one of the Wicket developers had to say about this statistic about a month ago:

... who says having a lists that has a lot of traffic is a good thing? It might just as well be an indication of a too-hard-to-understand framework having insufficient documention.

In the past couple of months, I've spoke in front of 25+ Java developers on 4 different occasions to talk about web frameworks. I've asked those developers which frameworks they've used, or plan on using. Struts is still the most widely used, with WebWork and Tapestry the least used. Surprisingly, JSF seemed to be getting no traction among the the audiences I spoke to. Even more surprising (to me at least) was that the most popular web framework continues to be the in-house framework. The overwhelming majority of the developers I've talked to aren't even using open-source web frameworks.

Integrating Lucene with Hibernate

The code_poet has an interesting post on using a Hibernate interceptor to index objects for Lucene searching. I've been thinking about integrating Lucene into AppFuse (or at least providing a tutorial) for quite some time. Hopefully this post will serve as a starting point when I do. I wonder how much the Lucene code can be simplified by the Spring support in the Spring Modules project?

Things I learned from OSCON

While at OSCON last week, I learned quite a few things. Many of these are my own opinions, so feel free to disagree with them.

Ruby is very cool

The main reason (for me) that Ruby is cool is because it's new. I don't have to know any of its history to know what makes it tick. It's easy to learn and has powerful language features that make it easy to use. I think the primary reason people, particularly Java developers, are excited about it is because it releases them from all the shackles they're accustomed to with Java. I have absolutely no plan to ditching Java and jumping to Ruby, but I do want to learn it so I can use it when it's a better fit than Java.

How to learn Ruby and retain that knowledge is the hard part. My current plan is to buy Programming Ruby and Agile Development with Rails. Unfortunately, I realize that I probably won't be able to finish these b/c I'll get bored and both will likely serve as more of a reference than a knowledge creator. I haven't been able to read a technology book cover-to-cover in several years. I couldn't even finish The Pragmatic Programmer for crying out loud. I realize that the best way to learn is to do, but the best way to do is to get paid to do. To facilitate this, I hope to develop some apps we can use at Virtuas. Of course, I'll try to find good open-source solutions first.

Rails has a lot of great ideas

The interesting thing about Rails is many of its good ideas are from Ruby. The built-in Webbrick web server is part of the language. The only way to come close in the Java world is to embed Jetty or something like that. I'll definitely be looking into embedding Jetty into AppFuse in the near future. The other thing I really like about Rails, and that I've been doing in AppFuse a bit is convention over configuration. As part of AppFuse, I'm already making a lot of decisions for users. The next step seems to be making all decisions for users, but allow them to override. It'd be cool to write some code that sweeps through all classes at startup and auto-configures them, w/o the need for any XML. If nothing else, the XML could be generated using reflection.

The biggest thing I learned from Rails is I need to provide 1) an easier upgrade path and 2) better Ajax support. Because I'm supporting so many different web frameworks, solving #2 might be a bit tricky - but could be done by writing tag libraries or components. Hopefully the framework developers will beat me to it and I won't have to do anything. As far as #1, I'm hoping I can move to a single appfuse.jar that contains all the base classes. Hopefully I can use a little JSP pre-compile action to re-use the existing JSPs for user management/etc. If not, I can always use something like FreeMarker to store the default view files in a JAR.

Creating Passionate Users is all about inspiring emotion

Kathy Sierra's talk about inspiring emotions among your users to make them transparently excited about your product/company was a real eye-opener. I can totally see what she's talking about and I'm happy to say I'm already doing some of it. This blog seems to attract lots of readers, some more passionate than others, just by talking about web technologies and Java. This does translate into more business for Raible Designs, whether it's the title image or URL, it doesn't really matter. Folks do figure out that I have a company and I do work with the technologies I talk about.

To apply these concepts to AppFuse and Virtuas is a little more difficult. For AppFuse, I can probably teach people how to better use Hibernate, Spring and Ajax - and then show how AppFuse can simplify things. Building in easy-to-use Ajax support is probably essential to really get this going. For Virtuas, we could re-vamp our site to provide education about open source and its history - providing users with a way to become open source experts. It would also be cool to do real-time reporting of how we helped a company adopt open-source.

Ideas, ideas, I have lots of ideas after last week.

Struts Ti

I heard about Struts Ti at OSCON, and after googling a bit today, I've discovered a bit more. Here's a bit about the project from Don Brown's proposal on the Struts Developers Mailing List.

Struts Ti is a simplified Model 2 framework for developing webapps which allows the developer better access to the underlying servlet/portlet environment. It serves a niche of web applications that don't want the additional complexity of server-side components and verbose configuration, yet want the structure and controller features of a modern web framework. Struts Ti builds on the directions of Struts 1.x, yet re-implements the framework to provide a clean slate for the next generation of Struts Ti. It aims to combine the simplicity of Ruby on Rails and NanoWeb, the refinement of WebWork 2, the tool-friendly authoring and Page Flow of Beehive, and the lessons learned from Struts 1.x.

The key word for Struts Ti is simplicity. Ideally, Struts Ti should approach Ruby on Rails levels of easy of use, yet scale up to large applications providing a smooth transition to JSF/Shale if desired.

More information can be found at https://www.twdata.org/projects/struts-ti.

[OSCON] Spring MVC vs. WebWork Smackdown

Matthew Porter and I's Spring MVC vs. WebWork Smackdown presentation was a lot of fun this morning. We had a boxing bell (that I got off eBay) and had a good time ragging on the two frameworks. The only surprise was that Matthew actually ran some metrics on the Spring MVC vs. WebWork code in AppFuse and pointed out that the WebWork version required 25% less code than the Spring version. Oh well. The hard part about this presentation for me was trying to defend Spring MVC and saying it's better than WebWork. Matthew obviously felt strongly that WebWork was the better framework, whereas I like them both.