Raible Designs

Can you base a web framework on another web framework?

It looks like the Struts guys are going to base Struts 2.0 on JSF (detailed proposal, wiki). It should be interesting to see a web framework developed on top of another web framework. Of course, it's been done before. The two things I really like in this proposal are 1) a built-in IoC container and 2) the security stuff (remember me, user registration). Here's the details from the proposal:

3.5 Service Provisioning APIs

Inversion of Control (IoC) containers (the techniques are also referred to as Dependency Injection) are becoming a popular mechanism for assembling the required services and logic of an application. If Struts included such a framework, it would provide a solid basis for building maintainable apps, as well as allowing the framework to configure itself using the same capabilities.

Rather than building such a container ourselves, we should seek to incorporate an existing one that is license-compatible and which can be integrated into the JSF managed beans facilities (so that value binding and method binding expressions can leverage the facilities of this container transparently). From my research so far, I like Spring's capabilities in this area the best, but am open to other suggestions.

3.6 Authentication and Authorization APIs

In order to support reasonably complete solutions for applications that wish to provide their own authentication and authorization services (as well as interact with container managed security), we need APIs available for performing user registration, implementing "remember me" features, and represent the results via a wrapped request (so that apps depending on getRemoteUser(), getUserPrincipal(), and isUserInRole() will still work). Using JDK 1.4 as a base platform would allow us to integrate mechanisms like JAAS. Other alternatives include plugins like SecurityFilter.

I added the emphsis on Spring. I'm all for this because 1) I'm on the JSF Expert Group (as of last week) and 2) it'd be nice to see JSF stretched, poked and prodded. IMO, JSF needs more "real-world" usage and the popularity of Struts will give it that. By "real-world" usage - I mean it needs to be used by developers that aren't cooped up in some cube with a fancy IDE. I also like the proposal because there's tons of Struts apps out there - and many of them might want to "upgrade". This means more (potential) work for me. Of course, I also plan on spending more time with Tapestry so I can offer client's an "educated" suggestion. BTW, the reason I joined the JSF EG is to be the "developer's voice" among the IDE Vendors. So if you'd like your voice to be heard - send me your suggestions, I'm all ears.

The question is - when will Shale be released? Of course, since it's open-source, the answer is "when it's ready". My guess is 1 year from today. I'm thinking of making AppFuse 2.0 use this new stuff. Of course, it'll have Tapestry and JSF options long before that.

If nothing else, the Shale proposal should motivate other web framework developers to highlight their roadmaps and what's new and cool on their horizons.

Comparing Web Frameworks Presentation

Since Kris let the cat out of the bag, I might as well give you the link to my comparing web frameworks presentation (PDF, 280KB). I also created a page on the Equinox site for this presentation and related materials. In addition to the presentation, this page also has links to the various framework implementation demos. Here they are for your convenience:

• Spring
• JSF
• Struts
• Tapestry
• WebWork

Kris notes that I would still choose Struts. I think it should be noted that I would only choose it in combination with AppFuse (which generates ActionForms). Same goes for Spring and WebWork. I've added interceptors and convenience methods that simply make developing with these frameworks faster and easier. I would've chosen WebWork for my current project, but I'd like to see better client-side validation. Spring needs better tag libraries.

I think the choice of what framework to use is a very personal thing. I think the "best" framework for one person might be very different for someone else. For me, I typically do short-term projects with clients - get them up and running with an application, and then head off to the next project. It makes sense for me to create applications that use a popular framework like Struts that they can easily find developers to maintain it. However, the one thing I'm starting to find is that as long as I use AppFuse - there's good documentation on how to do things. So I've already written the "how to develop and extend this app" for future developers of a client's application. This will (hopefully) open the door for me to use any web framework that AppFuse supports.

I think WebWork rocks, but it's similar to JSF in that it doesn't come with everything your need. The good news is it's easy to write interceptors, but IMO there's a few that should be part of the framework. After working with Tapestry and JSF, I can see how component-based frameworks will be the wave of the future. I think as you develop more and more components, the code you write becomes less and less. It's funny that this is one of the goals of AppFuse - incorporate a bunch of tips and tricks for various frameworks to make development easier. By adding support for Tapestry and JSF, hopefully AppFuse will someday become a repository of useful components. Documentation is good - code is better.

I'd probably be more enthusiastic about Tapestry and JSF if I knew more about them. I still have a lot to learn. I've bought the books (Tapestry in Action and Core JSF), I just haven't had time to read them. I think after incorporating these frameworks in AppFuse (hopefully this year), I'll get a better feel for them and how they make development faster and more efficient. My major problem with JSF is that it's being written for the tools vendors and not for the developers. Make it easy for everyone, not just folks that want to use their hammer-like IDE to develop webapps. The major problem I have with the JSF Tools is 1) none of them are free and 2) most of them are tied to a proprietary app server.

CruiseControl and AppFuse Redux

Thanks to Mike Clark and Jared Richardson, I was finally able to get AppFuse to work with CruiseControl. Checkout the AppFuse with CruiseControl wiki page for more info.

[ANN] Equinox 1.1 Released

In preparation for my talk on comparing web frameworks, I've made a bunch of enhancements to Equinox. I changed the default web framework to be Spring and added a very simple "CRUD users" feature. While it's basic, it shows how to do validation, success messages, and a sortable list with the following frameworks: Spring, JSF, Struts, WebWork and Tapestry. I even added a "birthday" field to demonstrate date-handling. I dig the built-in popup calendars that ship with JSF and Tapestry.

• Download
• Demo

Oh yeah, I also added a hack (from James Violette) to make the Display Tag work with JSF. Code says it best. I plan on writing a detailed how-to as part of the Display Tag's documentation. Suggestions for a cleaner hack are welcome.

In other display tag news, here's another way to do static headers.

AppFuse a top 10 java.net project?

I don't know if it's really a top 10 project, but it gets lots of hits, accesses and mail traffic. Nice! I'm willing to bet it's the cool logo that's the source of its popularity.

BTW, I'm giving a talk on AppFuse at Denver's No Fluff Just Stuff in two weeks. If I can finish up the "appgen" tool by then, the talk could be a lot more fun as the demo would be short and sweet. I doubt it'll happen though. I'm knee deep in creating a version of AppFuse Light that showcases how to use Spring with Hibernate and your choice of web framework: Struts, Spring, WebWork, Tapestry or JSF. I hope to release it sometime this weekend or early next week. Next week (and likely the week after), I have to write Chapter 10 of Spring Live. That leaves almost no time for creating the next cool tool. Who knows though - it might be easier than I think - especially since Lance submitted a good start.

Trails - like Rails, but with Tapestry, Spring and Hibernate

I've been thinking about Rails ever since I wrote a post about it on Monday. The main reason is because of Dion's comment:

Matt - You should follow the lead and do a video of setting up a simple app using AppFuse.

This might sounds like a good idea, but if I did it right now in AppFuse's current state, it'd be a disaster. The reason? Because you have to manually create a whole bunch of classes to do CRUD on a database table. Here's a list of new classes needed for adding a new "person" table.

• model.Person
• dao.PersonDAOTest
• dao.PersonDAO
• dao.hibernate.PersonDAOHibernate
• service.PersonManagerTest
• service.PersonManager
• service.impl.PersonManagerImpl
• webapp.action.PersonActionTest
• webapp.action.PersonAction
• web/pages/personList.jsp
• web/pages/personForm.jsp

The last two JSPs can be generated, but that's still a buttload of classes (9) just to CRUD (and test!) a database table. Not too mention all the files you need to edit for Spring and i18n.

• dao/hibernate/applicationContext-hibernate.xml
• service/applicationContext-service.xml
• test/web/web-tests.xml
• web/WEB-INF/classes/ApplicationResources_en.properties
• web/WEB-INF/menu-config.xml

Result: to CRUD a database table using AppFuse you have to create 11 new files and modify 5 existing files. 16 files. What a beotch, huh? If I made a video of this - it'd be 20 minutes long! While this might make AppFuse look silly, it's really more of a symptom of the patterns we have in J2EE and how we're supposed to architect our apps. 3 tiers, test-driven, loosely-coupled and internationalized. Of course, if I was focused on fast and efficient, I could do this all with 1 JSP and JSTL's SQL tags. Everyone would slap my hand for not following patterns, but I'm willing to bet it'd work just as well and be just as fast. But I digress.

There have been a fair amount of requests (and some patches submitted) to generate and modify all of the files listed above. For the most part, I've frowned upon adding such a feature because I think if folks can run "ant generate -Dmodel=Person" - they'll end up with a whole bunch of code that they know nothing about. Sure there's the tutorials, but folks will quit reading those. Instead, they'll create a whole slew of POJOs (maybe even using Middlegen) and run "ant generate" on all 50 of them. Poof - now they've got 550 new files to maintain. Talk about a maintenance nightmare. Even worse - a support nightmare for me.

Nevertheless, if I wanted to create a cool video for AppFuse, I'd spend a few days writing this code-generation engine. Then I could show how you could create the data, service and web layer (including UI) in a matter of seconds. It'd be cool and folks would dig it. I'm still considering it, but I'm also leary of the resulting support fiasco. Maybe I could just say "use at your own risk".

A while back, I saw Erik Hatcher suggest a better solution than code-generation. I can't remember what he called it, but it was something like "meta-data dynamic rendering". The idea is that your application reads the metadata of a table (or POJO) and renders the appropriate UI for it. I loved the idea as soon as I heard it. I've always wanted a way to dynamically render the UI rather than writing HTML. Of course, I still want the ability to edit the templates and HTML since I fancy that sort of stuff. I don't like writing HTML for each row in a form, but I do like tweaking the HTML and CSS to look good.

Earlier this week, I saw the concept in action with Rails and its demo. IMO, something like Rails would never fly in Java because it appears to be tightly coupled to the database and only MySQL, PostgreSQL, and SQLite are supported. The Java community always seems to pride itself on database abstraction, partly due to JDBC and its ability to connect to anything that has a JDBC Driver. Ruby will probably catch up someday, but right now it appears to be looking for something like JDBC.

Then along comes Trails, which made me smile earlier today when I first read about it on the tapestry-dev mailing list.

I've been working on a project called Trails that uses Tapestry quite heavily and I thought it time to start soliciting feedback. Trails is a domain driven development framework that uses Tapestry, Spring, and Hibernate. Trails is very much in it's infancy, but the current version is functional and should give people a rough idea where I am heading. It's my first real forray into Tapesty and I have really found Tapestry a joy to work with.

Trails is very much like Rails, except that it doesn't talk directly to a database table. Instead, it talks to your domain objects that you mark up with XDoclet/Hibernate tags. To test it out, I dropped a User.java file into the org.trails.demo package, marked it up with XDoclet and deployed. It didn't work at first because the .hbm.xml files are explicitly listed in Spring's applicationContext.xml. I changed the "sessionFactory" bean to use the following and wammo - success! I could list and CRUD the table that my User object was mapped to.

  <property name="mappingDirectoryLocations">
    <list>
      <value>classpath:</value>
    </list>
  </property>

Trails is very cool, and I'd love to incorporate it into AppFuse or Equinox. Does an LGPL license allow me to do this? The one problem I can see with adding it is that it's specific to Tapestry and Hibernate, which doesn't always suite folks. I think developers might be willing to change because this solution will vastly improve their development productivity, but who knows. I think the best solution would be to offer this option in AppFuse/Equinox, but also offer the current manual and code-generation options. The holy grail would be the ability to plug in iBATIS or JDO instead of Hibernate. In addition, using Struts, Spring, WebWork or JSF instead of Tapestry would have folks clammering to use this stuff.

Mad props to David Heinemeier Hansson and Chris Nelson - you guys are developing awesome software.

Fun with Log4J and JBoss

I've had the pleasure of working with JBoss (3.2.5) and an AppFuse-based application for the past week. It was fairly easy to setup thanks to Rick Hightower's instructions. AppFuse uses commons logging (like many of its open-source dependencies), but uses log4j to control what gets printed to where. By default, it changes Hibernate and Spring to use WARN and the application classes to use DEBUG. For most containers, this works great. Drop in the WAR, or package it in an EAR and voila - your logging statements show up in the console. Not so with JBoss. Spring and Hibernate use INFO and I can't get any debug statements to show from my classes.

I shouda known this would be a pain since Rick wrote "Setting up logging is a pain in JBoss. Don't mess with the console log... it misbehaves. Create a file logger and tail it.". Is this the best practice for logging with Log4J in JBoss?

You'd think printing to the console would be easy. This wiki page even makes it look easy: change your log4j.properties to log4j.xml and add a <class-loading> snippet to your jboss-web.xml. Unfortunately, I get this nice error message:

00:21:17,593 WARN  [DeploymentInfo] Only the root deployment can set the loader repository, ingoring
 config=LoaderRepositoryConfig(repositoryName: log4j.config:loader=appfuse.war, repository
ClassName: org.jboss.mx.loading.HeirarchicalLoaderRepository3, configParserClassName: org.jboss.mx.l
oading.HeirarchicalLoaderRepository3ConfigParser, repositoryConfig: java2ParentDelegation=false)

Any ideas are appreciated - it seems wrong that I have to write to file just to tail it so I get the same console behavior I get with other servers.

Using CruiseControl for Automating AppFuse Builds

After seeing Mike Clark speak at Denver's JUG earlier this month (download presentation), I became slightly motivated to try and get automated builds running for AppFuse with CruiseControl. It's fairly easy to do with Anthill, so I figured CruiseControl couldn't be too much harder.

After countless hours of trying to get it to work, I give up. I've documented what I did, and where I'm at - but I can no longer afford to spend any time on it. If you're motivated enough, feel free to try and get it working. Suggestions are welcome, but likely won't be acted upon since I'm burned out on CruiseControl.

Rails - the MVC Framework for Ruby

When I first saw the quick setup for Rails video, I dismissed it as a something simple that wasn't that cool. Thanks to Dion's post, I decided to watch it again. Then I realized why it looked so simple the first time - the video kept looping and all I saw was the Apache setup part - I didn't see the whole video. After watching the video this morning, it's enough to make me want to become a Ruby developer and use Rails to develop my next webapp. Then again, Ruby probably doesn't pay the bills nearly as well. The upside is it looks like it would actually run fast on OS X instead of the dog-slow Ant/Tomcat/Eclipse/IDEA combination.

Hopefully I'll get to learn more about Rails at Denver's upcoming No Fluff Just Stuff. It looks like Dave has added it to his repertoire. I wonder if Rails has support for using the Copeland IoC container?

AppFuse's License

Someone sent me an e-mail today and made me aware that the Commons Attribute License that AppFuse uses only applies to documents and such:

"Collective Work" means a work, such as a periodical issue, anthology or encyclopedia, in which the Work in its entirety in unmodified form, along with a number of other contributions, constituting separate and independent works in themselves, are assembled into a collective whole.

Because of this, I'm thinking of switching to use an Apache 2 License. This seems to be the friendliest license for open source. Basically, all I want to do is try to get folks that use AppFuse to give it some credit. Which really means they're marketing it in a sense. More marketing -> more users -> (hopefully) I'll stay employed and the product will get better.

The only pain I can see about licensing with an Apache License is they want you to add a short copyright notice at the top. But I'm not really handing the copyright of AppFuse over to ASF, am I? Do I have to add this copyright to all my .java files? I know that Spring does this, but... ugh ... seems rather unnecessary.