Raible Designs

[DJUG] Testing and Handling Exceptions in the Web Tier

I'm attending Denver's JUG tonight, where Scott Davis is talking about Unit Testing the Web Tier. His opening slide says he's going to cover HttpUnit, Canoo WebTest and JMeter. I'm most interested in the JMeter stuff as I've been meaning to integrate it into AppFuse. I've used HttpUnit and it's a little verbose for me. I prefer using Canoo WebTest or jWebUnit over HttpUnit. On my current project, we're considering using jWebUnit or HttpUnit to act as a browser when interacting with a 3rd-party system.

All of these tools run functional tests - which are much different from unit tests. Unit tests usually tests the bricks, whereas functional tests test the building. For unit and functional tests to be truly effective, they must be:

• Scriptable
• Repeatable
• Automated
• Darn close to 100% coverage

The tools Scott is talking about tonight have passed his basic tests:

• Can I learn it in 10 minutes?
• Does it play nicely with my existing test environment?
• Does it play nicely with my existing production environment?

I didn't take any notes about HttpUnit or Canoo WebTest because I didn't really learn anything new. Scott did do a nice job in his HttpUnit examples - he made it look a lot simpler than I've previously seen. I've used it HttpUnit before and it seems a bit verbose. I've always used jWebUnit, which simplifies HttpUnit's API.

JMeter allows you to do the same thing as HttpUnit and Canoo WebTest. It's a standalone GUI, for the complete non-programmer. It does not plug into Ant/JUnit and is mostly used for load testing. I thought it was exclusively used for load testing - and I think it has an Ant task. I could be wrong.

<sidenote>Scott uses Smultron for XML editing on his Mac.</sidenote>

The basic building block of JMeter is a "Thread Group". The Thread Group allows you to control the number of users/threads that run a particular test. You can test gets, posts, change the protocol and even upload files. For load testing, make sure and check "Retrieve all Embedded objects in HTML files". You have to view the "result windows" to view that your tests actually ran - there's no "green bar" feature.

I think JMeter has improved a lot since I last looked at it. Scott's overview and demonstration make it look very straight forward and easy to use. One guy asked if it's possible to see a a global view of all tests run. Scott thinks it's possible by adding a Listener to the Thread Group and creating a graph (one of the options). Scott is now showing a lot of the options in JMeter - there's a ton! It's almost overwhelming.

Next up is "Exceptional" Web Apps by Stephen A. Stelting, a senior Instructor and Author from Sun. His latest book is "Robust Java". Stephen has spent the last year and 1/2 figuring out how to make Java fail.

Objectives:

• Describe the types of errors that occur in the web
• Explain how exceptions and errors can be handled
• Describe the web container response to exceptions
• Present best practices to address web tier exceptions
• Show how web frameworks handle exceptions

Payoff: As a result of this talk, you'll have a better understanding of how to use exceptions in Servlets and JSPs, improving the robustness of your webapps.

I'm a little skeptical at this point. I think most folks don't do exception handling in their webapps. I hope Stephen has some good tips and tricks for those of us who are familiar with handling exceptions. I wonder how he feels about Spring and its runtime exceptions?

There are two types of exceptions in the web tier: HTTP Errors and Java Exceptions. Standard HTTP Errors are handled by the web server. You can also send your own HTTP errors by calling HttpServletResponse.sendError(). If you're using response.sendError(), make sure and call it before you commit the output. The web.xml file allows you to specify errors and exceptions with the <error-page> element.

Servlets and Filters have similar exception behavior. Both declare exceptions in both of their lifecycle methods: init and service (doFilter for Filters). Developers throw exceptions in lifecycle methods to "tell" the container about problems.

• javax.servlet.ServletException
• javax.servlet.UnavailableException
• java.io.IOException

Stephen is now describing the init() method and the exceptions it can throw. Yawn. I think most Java web developers use frameworks these days. Because of this, most developers probably don't use these methods because they don't write plain ol' servlets. One thing I didn't know is that UnavailableException takes a time parameter - if you throw an UnavailableException with this parameter, the container will retry after the specified amount of time.

Result of Exceptions in init(): The destroy() method is never called, since the initialization did not complete. Client calls during component unavailability render a 500 error.

I stopped taking notes at this point because my laptop battery was dying. I didn't really learn much in the rest of the presentation. While I can appreciate Stephen's enthusiasm, it was obvious that he was an instructor and not an in-the-trenches developer. He explained a lot of what and didn't have any code to show how to do stuff. There wasn't a single demo in the entire presentation.

Most of the exception handling stuff Stephen talked about for the rest of the session was common sense (IMO). It also centered around the Servlet and JSP API, which most folks probably don't mess with. The Struts and JSF coverage at the end was cool. If nothing else, it was to nice to hear a Sun employee confirm that JSF is quite deficient in its hooks to allow easy framework-configurable exception handling.

Now that I'm working at home, and working/interacting with friends all day - it seems that the DJUG meetings aren't as exciting. They used to be fun because I could get out of the house and have a few beers with friends. Maybe it was the lack of learning anything new tonight.

XmlHttpRequest

Dave quotes it, Charles writes it. XmlHttpRequest is the topic at hand and how it will help us build the next generation of web UIs. I've used Brent Ashley's JSRS Library to do some fancy UI work (one drop-down populates another) last year. It worked well in combination with Erik Hatcher's articles: Remote scripting using a servlet and Sending rich messages between client and server using asynchronous messaging. The project was AppFuse based, so I have the code if someone really wants it.

An example of XmlHttpRequest is in Roller itself - in the twisty comments you see on this site. For those who have used them, you probably know they're somewhat buggy. With all this talk of XmlHttpRequest, maybe it's high-time to revisit Roller's implemenentation and see if the technology has gotten any better. In reality, I know it hasn't - it's the browsers that are the problem and there hasn't been an update to IE in quite some time. My code could probably use some work though. If you want to dig in and check it out, here's the xmlextras.js that does the heavy lifting and comment-specific JavaScript.

After looking at this code this morning, it looks like there's different methods being used for the different browsers.

/////////////////////////////////////////////////////////////////////
//// XML Document loading

function loadXMLDocument(aURL, aCallback)
{ 
  gMediaCallback = aCallback;
  
  if (window.ActiveXObject) {
    // Internet Explorer XML loading syntax
    gMediaDoc = new ActiveXObject(getControlPrefix() + ".XmlDom");
    gMediaDoc.onreadystatechange = onMediaReadyStateChange;
    gMediaDoc.async = true;
    gMediaDoc.load(aURL);
  } else {
    // Mozilla XML loading syntax
    gMediaDoc = document.implementation.createDocument("", "", null);
	var xmlHttp = new XMLHttpRequest();
    xmlHttp.overrideMimeType("text/xml");
	xmlHttp.open("GET", aURL, false);
	xmlHttp.send(null);
    gMediaDoc.loadXML(xmlHttp.responseXML.xml);
    onMediaLoaded();
  }
}

I wonder if there's a common way that can be used for both browsers? BTW, 99% of the code for these comments was borrowed from Joe Hewitt.

Later: Another article covering this technology: Using the XML HTTP Request object. Hat tip to Carl.

Integrating JSF and Tapestry into AppFuse

Well it looks like I accomplished my goal for the year: integrate Spring MVC, WebWork, Tapestry and JSF into AppFuse. I decided to integrate JSF and Tapestry at the same time so I could get a good feel for their differences. Also, I figured there would be a lot of similarities I could re-use between the two. I found this to be a great idea. Often I'd use the first framework as a template and the second would go much quicker. It turned out to be a good strategy because I often found bugs in the first while working on the second. I really enjoyed developing with both JSF and Tapestry - here's my notes from my development marathon over the last week:

Tapestry

• For Tapestry, I created a patched version of the 3.0 source. I did this because I wanted some non-standard things, like friendly URLs, a global properties file and a popup calendar that works with IE/XHTML. The Tapestry Community was gracious enough to supply the source - so I didn't have to do much patching myself.
• Pure HTML, like Tapestry has, is ssoooooo much nicer to work with. The syntax highlighting in HomeSite is fully functional again! I've been an HTML developer since 94 and I felt like it was 97 all over again - when we didn't write apps, just static HTML.
• Overriding the default Tapestry ValidationDelegate was pretty easy - and there's even an example in Tapestry in Action. I was able to add asterisks for required fields and error messages next to the fields fairly easily. Erik Hatcher also hooked me up with a Label component for non-validating fields.
• For the contrib:Table component, you can easily i18n column headings by using "keyName:propertyName" as the column value. However, if your keyName has a period in it (i.e. user.username), you can't override the ValueBlock b/c user.username is an invalid OGNL expression. I patched Tapestry to solve this.
• The ability to use <span key="keyName"/> to render i18n keys is awesome. So simple.
• Tapestry has a very rich validation framework that requires virtually no configuration. No setting up your resource bundle, etc. It just works. Client-side too.
• It would be nice to show all the client-side validation errors in a single dialog instead of one-at-a-time (WebWork does this too).

JSF/MyFaces

• I like how you don't have to create mappings - just link to the .jsp with an .html extension.
• For some reason, when I save a user and server-side validation occurs, the user's username and roles disappear. Good thing client-side validation is available.
• It was easy to override the Labels to add asterisks thanks to some code from David Geary on the MyFaces mailing list. In order to make it work, I had to ditch my HTML <table> and use an <h:panelGrid>. Now my JSP is Tag Soup. I think JSF is going to have to ditch JSP if they want to get anywhere. Hopefully JSF will soon support HTML templates like Tapestry and parse them with a Servlet Filter or something.
• It's unfortunate that I have to specify a "styleClass" attribute on all my <h:message> tags - I'd like to just set a default for these tags (others too).
• I ditched JSF's message setting and opted for setting my own List of messages in the session and then grabbing them out with a MessageFilter. This was so much easier to implement than the standard JSF message setting stuff.
• I'd rather not have to specify <f:loadBundle> at the top of each page. It's going to be the same for my whole app - it'd be nice to set a default bundle and variable name that all tags could access.
• It was quite a bit easier to integrate JSF into AppFuse than Tapestry. This was mainly due to the fact that I could re-use a lot of the JSP code, as well as the WebWork Actions are pretty close to the JSF Managed Beans.
• Spring Rocks - it never caused any issues with either framework. I just wish MyFaces wouldn't warn that it can't find a variable that it's already found. I had to turn logging down to FATAL so I don't get any meaningless messages from MyFaces.
• With JSF, why do I have to specify the supported locales in faces-config.xml? Why can't it look up the available bundles like JSTL with Spring/WebWork/Struts does?

So after all of this, which is my favorite? Unfortunately, there is no clear winner. They're both pretty cool, but not that much better than Struts, Spring or WebWork. In reality, I like them all, that's why they're all integrated into AppFuse!

Update: I forgot to mention that I was very pleased with the latest version of Canoo's WebTest. It now uses HtmlUnit at its core and its JavaScript support has vastly improved. I wouldn't have been able to do integration testing on the JSF version without this (updated) library. Not only did it work great, but it found XHTML issues in my code - that rocks! The JSF and Tapestry versions of AppFuse are the only ones that run Canoo tests with JavaScript turned on. This is mainly because the old tests worked fine w/o JavaScript and I didn't want to break them.

Edit Screens with JSF

I'm working with JSF this morning and I'm finding one thing particularly annoying. I'm working on a simple master/detail screen and I'm tweaking the detail screen to fit my needs. It's just a <form> with some form elements. I change something, run "ant deploy-web" and hit "refresh" to see my updated page. Since everything in JSF is a post, I get prompted to re-submit the form. Fine, I agree - then I'm returned to the list screen. Argggh - why can't I just view the form again?! This might just be a MyFaces nuance, I'm not sure. Anyone know of a workaround?

Wanna see the bug/feature in action? Go to http://demo.raibledesigns.com/equinox-jsf/userList.html, click on a row - and after the edit screen displays, hit refresh on your browser. In an ideal world, you'd see the form again, but nope - you get the list instead.

Tapestry by Example with Erik Hatcher

It's Saturday morning and I plan on learning more about Tapestry this morning. There's pretty light attendence in the room. Too bad - I bet if it was a JSF talk, the room would be packed. In this talk, we're actually going to build a real application on-the-fly.

Why another web framework?

• HTML should be HTML
• JavaScript Embraced
• Reusable components
• Free developer from dealing with plumbing
  • Request/Response
  • Session/Application Scope
  • URL Mappings (nice, but leads to ugly URLs)
• Event handler driven
• Asset handling
• Line-precise error reporting

Erik says its one of the few frameworks that embraces JavaScript so much. I dig this b/c I think JavaScript is important for web development. Look at what the GMail guys have done with JavaScript. It'd be wicked cool to have this sort of thing open-sourced so we could all create GMail-type interfaces.

Dirty Laundry

• Heavy Duty - can be overkill for small/simple app
• Potentially steep learning curve. More of an un-learning curve. The Servlet API isn't in your face - so all that knowledge is useless.
• Not widely accepted - managers haven't heard of it
• Some awkward conventions (i.e. abstract classes)
  • and some non-intuitive necessary tricks
• Unit testing tough - do you unit test your swing app's listener methods?
  • Tapestry Test Assist should solve this problem
  • Howard's caught the TDD bug, so this should get better
• Lousy URLs - there's a patch on the wiki to fix this
  • Tough to do hit/stat tracking
  J2EE declarative security
• Example applications
  • Workbench and VLib included with Tapestry
  • Better Pet Shop

Workbench Demo - DatePicker component does do i18n (very cool!). Client-side validation does one-field at a time, like WebWork does. I prefer the "all messages in one pop-up" approach that Commons Validator has. Pallete component looks very cool - you can move and re-order items from a multi-select on the left to a multi-select on the right. Chart component looks pretty cool - you can generate graphs very easily. Unfortunately, it's not part of Tapestry, but you can see how to do it in the Workbench app. If you want to see an online version of the workbench, I have it setup on my server.

Repositories for components: Tacos, Tassel, T-Deli and a few mentioned on the wiki.

To bring a component to life, you simply add a "jwcid" to an HTML tag. You can specify initial values for page properties using <property-specification initial-value=""> tag in your template's .page file. The value is implicitly an OGNL expression, and you can define lists using "{'value1', 'value2', 'value3'}". This is great for prototyping before you have a backend or even a page class. To remove elements in a page, specify jwcid="$remove$" on an HTML element and it'll be removed at render time. The restriction is you can't have Tapestry components inside a $remove$ component.

If you don't want to use abstract methods (and hence classes) in your page class, you can use getProperty()/setProperty() methods. However, the recommended way is to use abstract methods.

Templates - two different types. You can put the @component stuff directly into your page - or you can use jwcid's and refer to a name that's defined as a <component> in your page-specification XML file. The Border component can be used to do page decoration like SiteMesh. You can use the Shell component to declare stylesheets/scripts on a per-page basis. This is something I do a fair amount, so it's nice to see it's built into Tapestry.

Internationalization - Resource bundles are component specific (one .properties per page). In a .page, you use <message-binding>. In a template (.html), you use attribute="message:key" or <span key="">. The "key" attribute can't be used on any ol' HTML element, only on the <span> tag. In .java, you use getMessage() and format(). You can also define a custom message source (i.e. read messages from a database). I'm impressed with how easy it is to do i18n in Tapestry. It's also cool that i18n is built-in for templates. Just include a locale extension on your page and it'll be rendered for users with that locale. For example, home_fr.html will show up for users with the French Locale.

Engine - gets all requests. Visit class - POJO that acts as like an HttpSession. You can configure it in the .application file. You can talk to your "Visit" class in a template using "ognl:visit". To call methods on it, just use "ognl:visit.method". Majority of services originate in the Engine. Generally override createXXX methods. Engines can be pooled or created on a per-session basis.

If you override the createXXX methods in Engine, you change the behavior for:

• message source
• global and visit
• property configuration
• template and component sources

contrib:Table - to override use <tr jwcid="columnColumnValue@Block"> - where "column" is the name of the column. Using this, you can easily put links and such into a table cell. Built-in TableModel can be used to talk directly to a JDBC DataSource. The TableModel is smart in that it only brings back the rows it needs to display. Add an exclamation point to the beginning of a column name to turn off sorting for that column. i18n is built-in for headers - the name of the column is simply looked up as a key in the page's .properties file.

Exception handling - Bail out by throwing an ApplicationRuntimeException. This tosses you to the default exception page, which you can override and "pretty up".

Validation - it's robust, but it can only validate <input type="text">. Erik thinks that Tapestry's validation framework could be much simpler and easier to use.

Dynamic Templates - can implement a IDelegateSourceTemplate and pull templates from a database or content-management system. To register your new TemplateDelegate, you can just register an <extension> in the .application file and point it to your class.

Page Lifecycle - initialize(), PageRenderListener(), PageValidateListener(), PageDetachListener(). Can use an ExternalCallback and ICallback to set properties on one page from another. Callbacks look very cool and there's a lot of discussions about them on the mailing list. The VLib app has a fair amount of callback examples.

This was definitely a good Tapestry session - thanks Erik.

[DJUG] Web Services and Geronimo

We're finally getting started at 6:25 and we were supposed to start at 5:50. Good ol' projector issues. This time it was a bent pin.

J2EE 1.4 introduced the first web services component type (SE) and augments EJB specification (2.1) to expose SLSBs as a web service endpoint.

Writing J2EE 1.4 web services ("endpoints")

Two J2EE components to implement a web service:

• JSE (JAX-RPC Service Endpoint). New component, new deployment descriptor. Looks like a servlet, acts like a servlet. Run's in a web container like a servlet. Isn't a servlet.
• SLSB. Exposed as web service via deployment descriptors.

JSE is easier because it's (mostly) POJO based. EJB might be preferred if you already have EJBs or you need transaction management. However, the SOAP client calling the EJB web service does not participate in the transaction (at least the spec does not define it).

"Mandatory" transaction attribute not allowed in EJB endpoints because SOAP client can't propagate transaction.

JSEs are similar to servlets:

• Instances run in the web container
• follow servlet lifecycle
• Must have a public no-arg constructor
• Can add servlet filters just like you do normally

Steps to writing a web service JSE:

    1. Write remote interface (the service endpoint interface) - must extend java.rmi.Remote and throw RemoteException
    2. Write implementation class
    3. WSDL Document
    4. Deployment Descriptors (web.xml and web-services.xml)
    5. Create WAR File

J2EE 5 will allow you to turn any POJO into a web service - no interface needed. Apache Axis can be used to generate the WSDL for you with Ant. You map the implementation class as a servlet, with a servlet-mapping and everything. The difference b/w JSE's and servlets is you can only map one JSE to one URL.

Writing web service clients. Client model is defined by the JAX-PRC 1.1 spec. You can write web service clients using three JAX-RPC techniques:

1. Generated Stub - Easiest. Done at development time. JAX-RPC is invisible to your code. Stub classes hide it. Runtime implementation will be tied to a vendors JAR because vendor tool will generate class based on WSDL.

2. Dynamic Proxy - Most Portable. Done at runtime. Your code asks JAX-RPC factory to create stub at runtime that implements SEI (Service Endpoint Interface).

3. Dynamic Invocation Interface (DII) - No Stub Necessary. Useful for tools - e.g. dynamically retrieve WSDL then show user on a GUI what services are available and allow user to select what should be called. Client sets URL, methods to invoke and required parameters.

Future of J2EE web services. JAX-RPC 2.0 (JSR 224) in the works. The goals of JAX-RPC 2.0 are several:

• Make writing WS simpler by using metadata and annotations.
• If you write an endpoint interface, your implementation class won't have to implement it.
• Remove requirement to define a remote object.
• Better support for document-centric web services.
• Integration with JAXB.

Tom's presentation was quite good for his situation. There was a *ton* of technical issues and he had to show his presentation on Chris Huston's Powerbook. This meant no demos since he had JBoss 4.0 and everything else setup on his Windows laptop. After flailing about for the last hour - he admits its time to buy a Mac.

Apache Geronimo

1. Apache Software License
2. Uses other BSD-derived, open source projects
3. Initial manifestation as a J2EE 1.4 application server 4. J2EE 1.4 certified (in-progress)

Started a year ago in September. The main motivator for Geronimo was there was no BSD-derived license for an open-source application server. The GPL license requires you to contribute code back if you customize a product. BSD allows you to do anything, you just have to give credit back to the originator. Sounds like the proper license for AppFuse to me.

The heart of Geronimo (the kernel) knows nothing about J2EE. It's designed to do just about anything you want it to do - it's just a configuration away. Jakarta project at Apache makes up a huge portion of ASF projects. Many of these projects are pieces of the J2EE puzzle. However, there wasn't any glue to hold it all together. Geronimo re-uses a *lot* of existing (best of breed) open source projects.

Geronimo still doesn't support Tomcat. The main reason is because 3 of the Jetty committers are part of the Geronimo team. Jetty was the first component every deployed in Geronimo. According to Bruce, someone is working on integrating Tomcat right now. You'd think this would be pretty easy and only take a couple days to do. Maybe I'm wrong.

Geronimo is NOT another lightweight container, web framework, or AOP framework.

It IS designed for long running servers. Its designed to tolerate partial component failures. System oriented services.

Geronimo Kernel - Fundamental Core

• Small memory consumption ~ 150KB code
• Component Registration
• Component Configuration
• Integrated Repository
• Lifecycle Control
• Dependency Manager

Now Bruce is going on about Maven and how it works. ZZZzzzzz. Maven schmaven. He does have a good point though - it works great for building and managing multiple projects and their dependencies. Geronimo has 30 sub projects - yow.

A lot of concepts and architecture in Geronimo is derived from Maven. Hmmm, I wonder if that means it's slow.

What are GBeans? They're a J2EE managed component (a JMX MBean), which are basically simple objects plus some metadata. Used to bridge JSR-77 lifecycle requirements. GBean wrappers allow just about anything to be plugged into be plugged into Geronimo. Implement the GBeanLifecyle interface: doStart(), doStop(), and doFail().

Bruce is now showing us the DerbySystemGBean that's used to stop and start GBean w/in Geronimo. Bruce has a lot of good things to say about Derby and thinks it's a much better database than both MySQL and PostgreSQL. That's a pretty strong statement, but since he met with Derby's architect last week, I tend to believe him. I'm assuming since I got AppFuse working with DB2 that using it with Derby would be pretty easy too.

Bruce says there's supposed to be a Geronimo release this week. I thought they were supposed to be done with Geronimo by this year's ApacheCon?

Now we're looking at an XML file that's a GBean configuration file. It looks like Spring is going to get some competition for long class names. And if you thought Spring's XML was verbose - Geronimo puts it to shame! I'm not saying this is a bad thing - it's just an observation.

GBean Archive - A JAR file that contains persisted GBean instances, GBean metadata. The Java classes in the GBean can reside in the JAR or be dependencies in a central repository.

GBean Descriptor - dependencies and configuration are defined in XML.

Repository: Structured collection of JARs. Designed to work in conjunction with Maven (pluggable implementation). Every JAR has a unique group and artifact id. Default repository is local file system, others allow auto-download.

Observation: Bruce's presentation is interesting - he seems to be targeting folks that want to dig into Geronimo and customize it. I think most developers just want to use it and would be more interested in seeing a demo of deploying an app on Geronimo, rather than how to integrate Derby or Jetty into the server. If it's so easy to plugin a component, why hasn't Tomcat been integrated? Maybe it's just me, I want to see it run and deploy apps to it - that's about all I want to do. In most cases, I shouldn't need to customize it. It's nice to know that it's an option though.

Basic Configuration Builder: Deployers are J2EE specific (JSR-88). If you have standards-compliant deployment descriptors - your application should deploy on Geronimo. Rather than calling them deployers, Geronimo uses "Builders". The Builders /deployers create configuration objects containing GBeans. Most complex Builder is J2EE deployer. It implements a JSR-88 deployment specification and accepts JARs, WARs, EARs, and RARs. You can also add in a deployment plan in XML. From this, a Geronimo Configuration ARchive (.car) is created. The nice things about these builder is you can do deploy-time optimizations, before the application is started.

Everything above the System Services and Kernel is hot swappable. You can remove the J2EE Configuration and replace it with something else like Pico or Spring. This means that you'll be able to swap out servlet containers w/o shutting down the server. That's pretty damn cool. If the system services and kernel are stable, and no JVM dumps occur - this means that your Geronimo server could be running forever. Sounds awesome.

High-availability (clustering, etc.) has not been built into Geronimo yet. This is primarily because this is not part of the J2EE spec. Developers are focusing on gaining 1.4 compliance, then they'll start looking at the fancy features.

Wow - good presentation Bruce. I feel like I know more about Geronimo than I ever wanted to know.

As I was getting ready to post the above transcript, I noticed that Geronimo 1.0 M3 was released. According to Bruce's presentation, this is the last release before 1.0. Nice work gents.

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.

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.

Comparing Web Frameworks: Presentation Outline

My Comparing Web Frameworks outline is due to the ApacheCon Planners today. I spent a couple of hours putting it together this morning and I'm mostly done. In reality, I know that I won't cover the things that everyone wants to know. In an ideal world, I could simply target the presentation towards people like me: they know Struts but want to learn more about the other frameworks. Before diving in, they want to know some things to watch out for.

The problem with doing that is writing for people like me sometimes backfires. I'd like to make it an advanced presentation, but I'm not an authority on all 5 frameworks - so that seems a bit far fetched. However, if I could add Tapestry and JSF support to AppFuse in the next two weeks - I'd have a lot more experience to refer to. But that ain't gonna happen - the first update chapter for Spring Live is due next week. OK, enough rambling - here's the slide titles I've come up with. So far, it's 22 slides and shouldn't grow any since it's supposed to be finalized when I submit it.

• Who is Matt Raible? My background, open source involvement, etc. Trying to give myself some credibility.
• Framework Experience: Long time Struts user, used Spring since end of last year, developed apps with other three this summer. AppFuse supports Struts, Spring MVC and WebWork; Tapestry and JSF coming before end of year.
• Meet the Candidates
  • Struts: Pros and Cons. Pretty much a standard, lots of examples, HTML tag library kicks ass. ActionForms kinda suck, can't unit test (only StrutsTestCase integration tests), Mailing list is swamped.
  • Spring MVC: Nice lifecyle (for overriding binding, validation, etc.) integrates with many view options seamlessly, IoC for easy testability. Not widely used, requires lots of code in JSPs, almost too flexible (no parent controller for SimpleFormController and Controller).
  • WebWork: Simple architecture, tag library easy to customize, interceptors are pretty slick. Documentation only recently written, few examples, client-side validation needs work.
  • Tapestry: Very productive once you learn it, templates are HTML (great for designers), healthy project. Documentation very conceptual, rather than pragmatic (lots of "read the book"). Steep learning curve, few examples. Impossible to test - page classes are abstract.
  • JSF: J2EE standard (lots of demand and jobs), fast and easy to develop with, rich navigation framework. Tag soup for JSPs, a bit immature (doesn't come with everything), no single source for implementation.
• Controllers and Views: Show controllers for all 5 frameworks and template page (JSP/HTML) for forms. Give URL to download sample apps.
• List Screens: How easy is it to integrate a sortable/pageable list of data? Struts, Spring and WebWork can use tag libraries like the display tag, value list or data grid. Tapesty has contrib:Table. JSF has dataTable component that requires custom logic for sorting (let me know if this has changed).
• Bookmarking and URLs: Struts, Spring and WebWork give you full URL control. Tapestry has ugly URLs. JSF does a POST for everything. Conclusion: first 3 play nicely with container-managed authentication. Tapestry doesn't (although there's a patch for pretty URLs). JSF is not friendly to bookmarking.
• Validation: Struts and Spring MVC can use Commons Validation - a mature solution. I've heard it's architecture is ugly, but who cares - it works! WebWork uses OGNL which allows powerful expressions. Client-side support is new and maturing. Tapestry has robust validation w/ good messages out-of-the-box. JSF has ugly default error messages, but is the easiest to configure.
• Testability: Struts you can use StrutsTestCase, which requires web.xml and struts-config.xml. WebWork and Spring allow easy testing with Mocks. Spring has a spring-mock.jar that can be used for mocking the Servlet API with any framework (it's not Spring-specific). Tapestry is impossible to test because page classes are abstract. The argument I've hard is "you don't need to test them b/c they're so simple." JSF page classes can be easily tested and actually look a lot like WebWork Actions (except they don't extend anything).
• Success Messages: The easiest way to solve the duplicate-post problem is to redirect after doing a POST. Struts is the only framework that allows for success messages to live through a redirect. It's fairly easy to get i18n messages in a Struts Action. Spring has nothing "built-in" for success messages. Long classnames / method arguments make it kinda clunky to get messages. WebWork has the cleanest way to get messages using a simple "getText()" method. Both require a custom solution to make your messages live through a redirect. Tapestry requires you to throw an exception to redirect and it still doesn't redirect (I haven't solved the duplicate post problem with Tapestry). JSF requires lots of code to get a ResourceBundle, but you could use Spring's IoC to inject a "messageSource" bean, making it a lot easier. JSF requires a custom solution for messages to live past a redirect.
• Spring Integration: Supported by all, sample apps have examples (quick slide).
• Internationalization: JSTL's <fmt:message> tag makes it easy in all JSP-supporting frameworks. Too bad there's not a standard for getting bundles in controllers and setting messages. Struts, Spring and JSF encourage you to use one ResourceBundle for all messages while WebWork and Tapestry encourage separate files for each page/action. This strategy is probably better for large teams.
• Page Decoration: I used to be a huge advocate of Tiles (using it since August 2001). SiteMesh is much easier to setup and use. Tiles can be used in Struts, Spring MVC and JSF. SiteMesh can be used with all 5 frameworks. In fact, the sample app uses the same SiteMesh setup for all w/o changing a thing. SiteMesh requires no maintenance, Tiles requires you add entries to tiles-config.xml whenever you add a new page.
• Tools: Struts has lots of tools available for it and even frameworks built on top of it (i.e. Beehive's NetUI/PageFlow). Spring has Spring IDE which is really just an XML tool for validating your bean and their relationships. WebWork has none (that've been released), but it is on the roadmap. Tapestry has Spindle, which is great for code-level programmers. It doesn't do drag-n-drop, but it does validate relationships between files. JSF has lots - but all of them cost money and tend to hook into proprietary app servers.
• Business/Marketing: Struts has lots of jobs and is well-known in the industry. A lot of enterprise applications are based on it. Spring is getting more press, but mostly because of the framework's other features. Knowing the rest of Spring is more valuable than Spring MVC. WebWork is gaining ground, but it's still virtually unheard of on job boards. If you do get gigs using WebWork, it's likely word-of-mouth and you'll probably be working with some pretty smart people. Often used with Spring and Hibernate. Tapestry needs more marketing - no one has heard of it, hence no jobs exist for it. JSF is quickly becoming the most popular. Want to stay employed? Learn JSF. The best reason: so you can back up your arguments on why you do/don't like it.
  
  Dice Job Count: Struts (1006), Spring (15 - not a very good name for searching, used "spring framework"), WebWork (14), Tapestry (9), JSF (147).
  
  
• My Opinion: You have to come to the conference for that . Slides should be posted following my presentation.
• Resources: Link and such for downloads, frameworks and tools mentioned.

Comments, suggestions, like it/hate it? Let me know. I expect to send this in in a few hours - so you'd better be quick!