Raible Designs

New JSPWiki Template - Springtime

I put together a new JSPWiki template this week - and I'm calling it "springtime" for now. I don't mean to reference "Spring" as in the Spring Framework, but rather Spring as in a fresh, crisp look. A lot of the styles I actually took from my Struts Resume stylesheet. For a demo, I've replicated my current wiki onto my demo server and changed the template to springtime. Whaddya think? Do you like it better than the "Redman" template I'm currently using?

Feel free to download either of these templates: Redman · Springtime

XDoclet vs. JSR 175

Rob Kischuk has a post where he describes what a Struts Action might look like using JSR 175 annotations.

@StrutsAction(
  @ActionMappings({
    @ActionMapping(
      path="index"
      @ActionForwards({
        @ActionForward(
          name="success"
          path="index.jsp"
        )
        @ActionForward(
          name="failure"
          path="error.jsp"
        )
      })
    )
  })
)
public class IndexAction extends Action {

As I read it, I though - "holy crap is that ugly!" Isn't the XDoclet version a bit cleaner?

 * @struts.action path="index"
 * @struts.action-forward name="success" path="index.jsp"
 * @struts.action-forward name="failure" path="error.jsp"

I'll admit, I don't know much about JSR 175, except that it is designed to replace XDoclet. However, I don't believe that it will generate code like XDoclet does - but rather it will allow your Java code to describe metadata using doclet tags. So what good does that do? Does this mean all my metadata and configuration stuff is hard-coded into my source? With XDoclet, I realize that a lot of this stuff is hard-coded into my source, but at least I can change things by changing an ant property and rebuilding - or changing the generated XML files. Why is JSR 175 better than XDoclet? I guess I just don't see the beauty of it. More typing and uglier javadocs aren't that appealing to me.

Weekend Releases :: XDoclet 1.2.1, Tomcat 5.0.24 and Cactus 1.6

While many folks were oohing and awwhing over how EJB 3.0 will make their worlds easier and app servers viable again - some folks continued to get things done:

• Tomcat 5.0.24 Stable: Change Log · Download. I'm pumped to see the Ant task declaration get simpler.
• Cactus 1.6: Change Log · Download. It's good to see the Resin support for the <cactus> task. Now if I could just find time to create a <runcontainer> task that allows you to pass in the server name (i.e. tomcat5, resin3).
• XDoclet 1.2.1: Release Notes · Download. I actually became an XDoclet committer last week - so hopefully that will help the Struts and Spring modules stay up-to-date. I'm using the current CVS version of XDoclet and it's working fine. The only problem is I had to hack it so it'd work consistently with Ant 1.6. This resulted in breaking 1.5.x compatibility.

BTW, thanks to all the Symposium Bloggers - with all the good reporting, I felt like I didn't miss a thing.

Struts Contract position in DTC

If you're an independent contractor, live in Denver, and know Struts - you might want to checkout this position. Requires: Struts, Tiles, JavaScript, DHTML. Sounds like a fun gig - contact me if you're interested and I'll give you the rate.

In a related note, I might have a contract opportunity for a local developer familiar with AppFuse and its technologies (most important: Struts, Hibernate, Spring and JUnit).

[ANN] AppFuse 1.5 Beta Released!

This release has lots of modifications that I've been meaning to make for quite some time. Specifically (1) removing the dependency on j2ee.jar and (2) removing Struts from the services layer. I also made improvements to Spring and its context file loading so you should be able to run unit tests from your IDE.

Other notables include full i18n support (with translations in Dutch, Brazilian and Chinese), improved setup-tomcat target (no additional JARs needed now), and an option to use Spring's MVC framework instead of Struts. If you'd like, you can read more about my conversion from Struts to Spring. Enjoy!

• Download (~12.2 MB)
• Release Notes
• Mailing Lists
• Demo

BTW, this upload was a little hefty for java.net at 12.5 MB - because of the iBATIS and Spring MVC option. My browsers (Mozilla and IE) kept timing out and I was getting a "Not enough space" error. To fix this, I had to increase the timeout on Mozilla. Here's the steps I went through:

• Type "about:config" in the address bar.
• Type "timeout" in the filter field and hit Enter.
• Change "network.http.keep-alive.timeout" to 600 (10 minutes). The default is 300.

Mapping buttons to methods

In AppFuse, I use Struts' LookupDispatchAction to map submit buttons to methods in my Actions. It's caused quite a headache for i18n, but Jaap provided a workaround and now everything works fine. However, as I did the Spring MVC implementation this weekend, I didn't have to do any complicated "button value -> method name" mapping. Part of it was because I didn't need to, but also because I discovered that you can easily just check if the button's name was passed in. Explaining this with code is probably easier. Let's say you have three buttons on a page:

The HTML code for the above buttons is:

<input type="submit" name="save" value="Save" />
<input type="submit" name="delete" value="Delete" />
<input type="submit" name="cancel" value="Cancel" />

Using the name as your key, you can easily check in your Action/Controller/etc. to see which button was clicked:

if (request.getParameter("save") != null) { 
    // do something
}

The nice thing about this is that it doesn't care what value you put on your button - just what you name it. It seems like all frameworks should use something like this, rather than a single parameter name (i.e. "method") that requires JavaScript on a button to change the method invoked. About a month ago, Rick Hightower mentioned that he uses a ButtonNameDispatcher for Struts. Rick, if you're reading this - I'm ready for that bad boy!

Converting AppFuse to use Spring for MVC

It's been a long and painful week - with 3 or 4 nights where I was up to 4 or 5 in the morning. Last night I was up until 4:30 and Abbie woke me up promptly at 7:30. Ugh, sleeping more is probably a good idea. I started on the Spring MVC layer for AppFuse on Thursday night and it took me almost 2 days to convert everything. There's still a few kinks and workarounds - but if you're running it through a browser, everything works the same as it did with the Struts version. The hardest part about it was writing the unit tests. With Struts, it's rather easy b/c I use StrutsTestCase, which provides a very simple API for testing Actions. I'm sure Spring will soon have this same capability with its Servlet API Mocks, but I was definitely banging my head against the wall a few times. I did manage to convert the LabelTag to recognize required fields and error messages. The JSP conversion was a slight pain - but mostly because you have to type a lot more for input fields than you do for Struts. I'm looking forward to WebWork which requires one line to do the whole table row. It has Velocity templates for its tags and they write the <tr>, <label> and the <input>. Pretty slick IMO - less typing is always attractive to me.

I'd like to write-up a detailed entry on "migrating from Struts to Spring" on JRoller, but it's been flakey over there for a few days now - so I might just do it here. We'll see - the lack of sleep is draining my motivation to write. I hope to do the Ant-based installation for Spring in the next couple of days - then I'll release 1.5 beta. My main reason for the beta is because the Spring stuff can probably be cleaned up a lot, as well as it gives me time to write documentation before the final release.

Populate your drop-downs with listeners and allow for refreshing

Most webapps have drop-downs (a.k.a. pick lists) that users select from when filling in forms. Spring has a nice referenceData method on its Controllers that you can use to populate these, but I prefer a different way. In AppFuse, I populate these using a ServletContextListener. However, one of the problems with using this is that your drop-downs won't get refreshed unless you have admins screens or a way to reload the attributes set in the listener.

In short, I think it's a good idea to load drop-down options in a listener and also have an action or servlet to refresh these options. For examples, see StartupListener.java and ReloadAction.java. Got a better way? I'm interested...

Weather.com: WebSphere to Tomcat and Oracle to MySQL

At my current client we're going to migrate our application from Tomcat to WebSphere 5 in May. I'm dreading the move and really don't see the point, but alas - the client is always right. However, since my client reads this website, I thought maybe they'd be interested to see that Weather.com recently migrated from WebSphere to Tomcat.

"It was hard to run WebSphere and an IDE [integrated development environment] because of all the resources WebSphere took," recalls Jeff Cunningham, who leads the Internet application development team at Weather.com. "You had to run an instance of DB2 on your machine because WebSphere stored its configurations in DB2, so you had to have all that overhead. It was just really slow. I just started using Tomcat for development because it was so much faster."

The article goes on to say that they evaluated other app servers as well, but chose Tomcat because of the team's preference. They also discovered that Tomcat served up pages significantly faster than WebSphere.

Weather.com is also working on swapping out its Oracle database for the open-source MySQL.
...
"Now when I talk to senior management about moving from Oracle to MySQL they don't ask me, 'Are you sure?'" he says. "They ask me, 'When?'"

It's a great time to be an Open Source Consultant. ;-)

What should we do with Tiles?

There's some discussions taking place on the Struts Developer Mailing List about what to do with Tiles. Tiles is gaining popularity in frameworks other than Struts - i.e. Spring and JSF. Personally, I don't mind that Tiles is buried deep inside struts.jar b/c it's basically the difference between a 500 KB JAR and a 100 KB JAR - and disc space is cheap! However, an advantage of extracting Tiles from Struts is that it then has the opportunity to become friendlier to other web frameworks. I'd even like to see a Sitemesh-like Filter so you could do Sitemesh stuff with Tiles. Or maybe just bundle Sitemesh with Tiles as a kick-ass templating engine.

So the question is: What should we do with it? Should it become a Jakarta Commons project or a Jakarta Project? Or even a java.net project? Tiles Users - we need your feedback!