Interview: Patrick Lightbody on Project Able - A Complete Java Web Stack

Posted by Scott Delap on Aug 15, 2006

Sections

Development

Topics

Web Frameworks ,

Java

Tags

Struts ,

TestNG ,

Hypersonic DB ,

Spring

WebWork committer, Patrick Lightbody, has announced Project Able: a complete Java web stack. Lightbody describes Able as:

it is an attempt to bring together quality opensource tools in one cohesive stack, similar to what Rails has done for Ruby, while also encouraging common practices I've used in software engineering for a long time ... It is very similar to projects such as Trails, Grails, and AppFuse. However, there are a few key differences:

• The stack components are different (WebWork, Spring, iBatis, etc).
  
• In addition to the basic framework, Able also encourages common development techniques and patterns (more below).
  

Project Able was started as a result of Lightbody's construction of HostedQA and BigBark. He realized the benefit in frameworks like Rails that provide the full stack of database layer, build infrastructure, and testing. The current incarnation of Project Able makes use of

• WebWork web MVC framework
• SiteMesh for web page decoration
• Spring IoC container
• iBatis OR mapping framework
• TestNG unit testing tool
• EasyMock mock object library
• Maven build tool
• Jetty for quick deployment during development
• HypersonicSQL for an in-memory database during development and testing

Currently Project Able is available as a collection of code checked into the OpenSymphony sandbox SVN repository. InfoQ sat down with Patrick to discuss how Project Able stacks up versus similar Java efforts such as Grails and Trails. In response to our question of what justifies another Java web stack integration project when there are at least 3 similar others in development (Trails, Grails, and Appfuse):

Good question - clearly I'm generally in favor of collaboration and consolidation rather than competition. I've shown this with the merge of WebWork and Struts. In this case, I think we first need to break down the comparison a bit more. AppFuse isn't exactly a true competitor, since it is specifically designed to allow for choice of various framework components. This is something we are avoiding with Able. So that is why I didn't work on AppFuse.

Grails uses Groovy, which while nice, doesn't really give the developer the full power of Java's refactoring and debugging tools that I think are necessary. I would say Able is most similar to Trails, with the exception that it uses an action framework (WebWork) rather than a component framework (Tapestry). And that's OK: I think that it makes sense to have one or two of these types of frameworks for each style of web MVC framework.

With that said, I have already spoken with Matt Raible (AppFuse creator) and we agree that in the future Able might be pulled in to AppFuse. So we're keeping an eye on it. I think there is room for some level of competition here - more so that Ruby. That's because Java is a much larger community and therefore has enough strength to accommodate several ways to attack a problem. It's only when there become so many alternatives that some are almost the same thing with different names, as was the case with WebWork and Struts, that it becomes a problem.

We then asked Patrick about the recent trend of Java frameworks moving away from abstraction, abstraction, abstraction and back to tighter integration between components being used:

Yes, though I think it's not just Java that is changing: all of opensource is moving in that direction. More and more, we're finding projects that eschew use of lots of smaller libraries and instead re-implement some of the the basics themselves, such as logging or persistence. RIFE and Rails are perfect examples of these. But so is, for example, a trend of ditching things like commons-logging and instead using JDK logging or log4j directly. I think people are realizing that there are a ton of great libraries to use out there, but the tighter they are integrated the more efficient they will develop. That is specifically why I think Able will be a great starting point for web developers.

The conversation then turned to the obvious question of why iBatis:

No reason, really. My reasons for choosing iBatis were:

1) It fails fast when there is a misconfiguration, which fits in to my philosophy about how a framework should work.
2) I like the control over the queries, especially with regards to joins and one-to-many and many-to-many relationships.

I haven't tried Hibernate 3 or JPA, so perhaps they will be good replacements. I'd be open to trying them out, provided that I can still implement all the same features that are in Able, including the ability to reload the Hibernate configuration on the fly.

Finally, in terms of one feature that is a key selling point of the Project Able stack:

the upgrade feature embodies the entire development philosophy of Able. It does two things: it brings attention to an all-too-often pain point in software development (upgrades) and also shows how you can enhance the "checkout and go" philosophy to apply to even your database changes.

1. Back to top

   Why not struts?

   by karan malhi

   Why not have struts as an MVC framework? I thought webwork and struts were working together for struts 2.

   Reply

2. Back to top

   Re: Why not struts?

   by Patrick Lightbody

   Good question - Struts 2.0 will be integrated in place of WebWork very soon!

   Reply

3. Back to top

   Re: Why not struts?

   by Pete the Wheat

   Afaik, Struts 2 is going to be more like Webwork than Struts "1" but it isn't yet released, not even a beta. Maybe that's why. :)

   Reply

4. Back to top

   Convention Over Configuration

   by Ben Rometsch

   Is there any chance of these convention over configuration changes being factored back into WebWork/Struts 2? It would remove 80% of most xwork files I would have thought, and make development a little faster...?
   
   Also, what about the REST based URL aspects? This would be a great addition to WebWork for those that dont want the full Abl stack...
   
   Great idea for a project tho. Appfuse/Equinox have helped enormously and could do with some company!

   Reply

5. Back to top

   Full Stack - The community is finally getting the message

   by Shimon Amit

   We're seeing it with Grails and JBoss Seam, and now Able. This is great. Thank you Ruby on Rails.
   
   Also, please include scripting at some point. It helps makes life easier. Yes, refactoring and tooling are important, but if there is demand, there will be supply. It's one of the basic rules of life.

   Reply

6. Back to top

   Re: Convention Over Configuration

   by Patrick Lightbody

   Ben,
   Absolutely - I hope to get the AbleActionMapper and AbleConfiguration stuff in to Struts 2.0. We've discussed it and I hope Able will help make it happen faster.

   Reply

7. Back to top

   iBatis

   by Marc Tremblay

   I'm currently moving a project off of iBatis to JPA. I'm amazed that anyone wastes their time with iBatis.
   
   Seriously, JPA isn't so complicated.

   Reply

8. Back to top

   Re: iBatis

   by Patrick Lightbody

   Marc,
   I definitely want to take a look at JPA - I've heard good things!

   Reply

9. Back to top

   Re: iBatis

   by Marc Tremblay

   If it's any help, we're using Spring 2.0 to provide standalone JPA to servlets. However, we are sticking to pure JPA in our code (not using any extra Spring features) such that we could easily move to another JPA container if we need to down the road.

   Reply

10. Back to top

    Re: iBatis

    by graham o'regan

    I like the direction JPA is heading, but I think Sun have made the usual mistake of not releasing enough in the first version and they don't have a "release often" strategy so we aren't going to see any improvements soon. To be really useful, JPA needed to have Hibernates Query *and* criteria API.
    
    As with Spring & IoC - use the standards if your company force you, but use Spring and Hibernate if you want the very best (not necessary latest) features. The last two contracts I have had have used Java 1.4 for a start :(

    Reply

• Older >