Raible Designs

MyJavaPack - an Open Source version of Blue Glue?

As noted by John Munsch, MyJavaPack looks pretty cool. At first glance, it looks like an open-source version of Open Logic's Blue Glue. Since I actually did some work on Blue Glue this summer, I downloaded MyJavaPack and did a a quick install.

I was quite impressed. All it did was download the packages I requested and installed them. In most cases, this is what I want - especially on my machine where I already have everything setup. Blue Glue goes a bit further than MyJavaPack. It installs and configures everything for you. This is great for brand new machines, but can be a pain for pre-configured machines since it adds stuff to your PATH.

The thing I like about MyJavaPack is that it's open-source. Therefore, I might be able to dig in and customize it for an AppFuse-based installer. Such an intaller would include tools for developing AppFuse: Ant, Tomcat, MySQL, Eclipse and AppFuse. That'd be pretty cool to be able to download and install an entire development environment.

Neither product does what we all really want: the ability to do an "update" (like Windows Update or Software Update on OS X) of our existing packages.

Tapestry Tutorial Roundup

I'm going to start integrating Tapestry into AppFuse in the next few weeks. There's nothing like a good set of tutorials to help this process along. Here's a list of current tutorials I found - let me know if you know of others:

• Introduction to Jakarta Tapestry
• Getting Started with Tapestry and Part II: Improving the Currency Converter
• Creating a Tapestry CRUD application

There also seems to be an up-to-date list of Tapestry Resources on Java201.com. I've started reading Tapestry in Action, so hopefully that will speed things up. I've made it to page 100 and I'm afraid I won't make it much further. I need to "just do it" more than I need to learn how to do it. I've often found that I learn a lot more after diving into the code and trying to do something and go back to reading when I start banging my head against the wall.

Integrating Tapestry into AppFuse shouldn't be that hard. I've already done it with the MyUsers application from Spring Live. Therefore, the Tapestry+Spring stuff will be easy. The only hard part, as far as I can tell, is going to be integrating Friendly URLs. Anyone got a patch for Tapestry 3.0.1?

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!

Rename Packages Tool for AppFuse

One of the steps recommended in AppFuse's QuickStart Guide is to rename your project's packages from "org.appfuse" to "com.company.appname". In the past this has been a real pain. I recommended using Eclipse, but this only worked for renaming the .java files themselves. It didn't catch all the package names in .xml and .properties files. Furthermore, it did nothing to change any references to "org/appfuse/model" or any other similar paths.

No longer folks. Ben Gill has developed a "rename packages" Ant task that'll zip through your AppFuse project and rename everything for you!

To use it, simply download it and view the README file to install and use. The source for this project is also available. This tool should work regardless of whether you've installed any options or not. Thanks Ben!

BTW, I should mention there will be an AppFuse 1.6.1. There have been a few bugs entered and fixed in 1.6 and I'd like to add support for Tomcat 5.5.3 (now in Cargo's SVN) and upgrade to XDoclet 1.2.2 (due for release soon). I'll probably wait until there's both Cargo and XDoclet have been released - in case some more bugs trickle in.

Estimating Projects

Martin Fowler has a good post on the Fixed Scope Mirage.

Many companies like the idea of writing a contract that fixes scope and price because they think it lowers their risk. The mirage says that their financial obligation is fixed at the price of the deal. If they don't get satisfactory software, then it won't cost them.

I see this often when looking for new projects. The potential client has a project they want done, and they want it done in X weeks/months. Why? Because they're willing to pay X dollars for the software and their next door neighbor (whose in IT) did an estimate for them while they were drinking beers the other day. I've learned my leason with these clients - run! Any client that estimates how long it'll take you to do something is going to be a nightmare to work for. Furthermore, if you get the gig - you've likely told them that you could do it in their timeframe.

Even worse are clients that want you to do a 1-2 week project. These are a nightmare because they tend to want lots of functionality, but don't want to pay for it - hence the 2 week project. From my experience, I've learned to only take clients that allow you to do the estimating and have projects that are a month or longer.

[ANN] AppFuse 1.6 Released

After many late nights and lots of Red Bull - AppFuse 1.6 is finished. Phew! The major additions to this release are SiteMesh and WebWork. I also did a lot to simplify DAOs and the tutorials. This release is definitely the largest AppFuse one I've ever done - or at least I spent the most time on it. Not only was WebWork added and Spring MVC improved, but I improved the Struts version significantly too. Now it'll handle nested objects, which can translated into nested forms - and validation even works. All classes in the "web" module can now be tested sans-container, which eliminates the need for Cactus and reduces test execution time by over 50%. The relationship between users and roles was also re-worked to take advantage of Hibernate's slick parent-child relationship features.

• Download
• Release Notes
• Learn more about AppFuse
• Live Demos:
  • Struts + Spring + Hibernate
  • Spring + iBATIS
  • WebWork + Spring + Hibernate

See the QuickStart Guide and Tutorials to get started right away. Enjoy!

fValidate - a Kick-Ass JavaScript Validation Library

I found this gem from Ben Alex on the Spring Forums tonight. fValidate looks to be an awesome client-side validation library. If you do a view-source on the aforementioned page, you'll see that all the validation rules are specified in the "alt" attribute of input elements. Apparently this is XHTML valid. Since the current implementation of WebWork in AppFuse doesn't have client-side validation, I may have to hack something together tonight. From the looks of it, this will simply involve adding an "alt" attribute to the existing WebWork tags.

Later: I think I'll pass on the AppFuse/WebWork integration - it looks like a fair amount of work and I'd rather just get 1.6 finished and released.

Resin slower than Tomcat, fails the AppFuse Test

As part of AppFuse 1.6, I was hoping to supply the option to use Resin instead of Tomcat. In reality, hardly anyone has asked for this on the mailing list - but since so many folks say that "Resin is better" - I figured I'd give it a whirl. I hate to be the guy that spoils all the Resin users mantra, but it seems like Tomcat is the better server. Why? Speed, compliance and shit works. Here are some things I found:

• Server startup time when AppFuse is only app installed (deleted work directories before starting):
  • Resin: 25 seconds
  • Tomcat: 14 seconds
  I also found that Resin loads my StartupListener twice b/c it's defined in web.xml and XDoclet puts it in the generated TLD. I think the best solution is to add a flag to XDoclet to allow you to exclude listeners from the TLD when it's generated. I commented out the entry in web.xml for this test.
• Running "ant test-canoo" which runs through all the JSPs using Canoo's WebTest (server already started):
  • Resin: 1st run (no compiled JSPs) - 53 seconds, 2nd run (compiled JSPs) - 24 seconds.
  • Tomcat: 1st run (no compiled JSPs) - 49 seconds, 2nd run (compiled JSPs) - 14 seconds.

I did have to hack a number of things to even run the tests (which verifies titles, success messages, etc.) on Resin. First of all, SiteMesh seems to puke with if you try to use <dispatcher>FORWARD</dispatcher> on the filter-mapping. I had to comment this out, resulting in a lots of HTML Tidy errors during the tests ( Error: <content> is not recognized!). I also had to turn off Resin's fast-jstl to bypass this bug. Finally, I had to revert the displaytag to using the non-EL version (which required changing titleKey -> title and name="${listName}" -> name="listName"). It seems that Resin enables EL even if you're using a 2.3 DTD. With Tomcat, and I believe the spec says this, EL is only enabled if you use a 2.4 XSD.

So there you have it folks, not only is Resin 3.0.9 slower than Tomcat 5.0.28 (JDK 1.4.2, Windows XP), but it's not standards compliant. Of course, the speed could be due to my using the open source version (with performance enhancements turned off) - but I'd think the other (albeit minor) stuff should be easy to fix. Everytime I try to use Resin, I end up finding bugs and going back to Tomcat. I guess this is another one of those days. I don't think I'll include a Resin installer as part of 1.6, but I might distribute one later if I can get these issues solved. I wonder if I should give Orion a run for its money?

P.S. Since I know people are going to ask: Tomcat 5.5.3 with JDK 5.0 took 9 seconds to startup. Running "test-canoo"? First run: 37 seconds, second: 14 seconds. Looks like the new compiler is quite a bit faster.

The New Gig

I started a new gig on Monday. For the next 6 weeks or so I'll be helping Oak Grove Systems enhance their Reactor products. I'm excited about the opportunity. I was going to use Equinox to build the prototype (due Monday), but since the final product requires security and user management - AppFuse is a more logical choice. I'd like to use WebWork or Spring, but since Oak Grove's reference implementation of their portal framework uses Struts, it's probably wise that I do the same so they can maintain it easier.

I almost went to work full-time and in an office - but now that I've chosen to take a gig with 100% work-from-home, I'm pretty glad I did. It would be tough to give up the musing-blaring, 23" monitor environment I've grown to know and love. The new office later this month will make it even nicer. BTW, the house is coming along and we should move in in a couple of weeks. Here's some pics: view from front, view from back and inside view.

Aren't out-of-container tests supposed to be faster?

Earlier this week, I converted my StrutsTestCase tests from using CactusStrutsTestCase to MockStrutsTestCase. At first, this seemed like a great thing - on my Windows XP box. To run all the tests in AppFuse, it takes around 2:20. I know, this is quite a bit of time for unit tests - but it was 3:15 in version 1.5. At least it's faster than it was. 1:20 of this is for starting Tomcat and running Canoo WebTests.

This all seemed great until I ran "ant test-all" on my PowerBook tonight. It averages around 7:00 minutes. WFT?! I know PowerBooks are slow - but they're not that slow. I'm guessing the reason is because Spring's ApplicationContext is loaded by each test - whereas the Cactus versions would always grab it out of the ServletContext. Sounds like I need a TestSuite.

What if I isolate and compare times for just the "test-web" target? This target runs all the Action, Filter and Listener tests. Time to execute on Windows: 33 seconds, PowerBook: 2 minutes 21 seconds. What about just testing the JSPs (with Cargo)? Windows: 1:24, PowerBook: 3:32. My Windows desktop has 1.5 GB RAM and a 2.6 GHz processor. My PowerBook has 1 GB RAM and 1.5 GHz. I agree that it seems like an unfair comparison - but AppFuse tests ran in around 4 minutes on the PowerBook in the last release. I guess it's back to the drawing board.

Update: Nevermind. I just downloaded and checked out AppFuse 1.5 - almost 8 minutes for running all the tests. If I were going to work on my PowerBook for my next project, I'd refactor AppFuse Managers and Actions to use jMock. Luckily I'm using my Windows machine.

Update 2: I found a solution! Using Ant 1.6.2's forkmode="once", I was able to reduce the time of the test-web target from 2:21 to 24 seconds on my PowerBook!! Windows: :33 -> :18. Running "ant test-all" on the Mac is now 2:15 - while the Windows version is 2:20.

WTF!? My PowerBook is actually faster than my Windows box? I never thought I'd see the day - Yeeee haaawwww!!

Now I just have to figure out how to detect 1.6.2 and warn users if they aren't using it.