As any product approaches version "10", there seems to be an aversion to using a version. Red Hat Linux stopped at 9 and merged with Fedora. Mac OS decided roman numerals were the go, Microsoft started throwing all sorts of years, letters, and marketing symbols behind the versions of their software.

Sun's application server isn't really that close to 10 (currently at 7 and I'm not sure there were really 6 versions before that), but it seems that the history of rebranding it is going to continue. Sun ONE as a brand is probably not that old itself, but it seems that the J2EE 1.4 RI will now equal Sun's application server (I'm not sure they were that much different before) and be called the Java System Application Server.

This move actually makes a lot of sense to me, but I wish they'd make up their minds!

I've actually been trying out S1AS7 recently as we are going to have to start doing some work with a JMS queue and don't currently own an application server. I've had some issues configuring it and loading any apps that use log4j, but other than that it was pretty simple.

It's been a long time coming (I promised myself this two years ago!), but I finally took the plunge and started writing some Cactus test cases.

I had it in my head that it was going to require a lot of work, but thanks to a lot of recent usability enhancements by the Cactus team, and a well-written Maven plugin, setting up was a breeze.

Once I had a simple test case in place, I just had to add 4 or 5 properties to my project.properties file, and run maven cactus to test the case against Tomcat 4.1 and Resin 2.1. Piece of cake!

We use webapp deployment descriptors in Tomcat 4.1 (and in resin via an xml entity included in resin.conf) to configure all of the JNDI resources which were necessary when moving onto a more complicated test case. I originally fudged around with trying to keep one copy of these but decided in the end that a customised server.xml with them included was the best solution for now.

Making the cactus plugin aware of these files might be one of my other side projects. There have been a few small things that can still be improved (which I promptly entered into bugzilla :) but overall it's great.

I also have to say that the documentation is quite good too - something usually missing in open source projects - which made a huge difference.

For those that couldn't be in Sydney to see Mike Cannon-Brookes speak at SJUG a few months back, this tech talk on TSS has a lot of similar elements in there. Interesting reading/listening depending on your preference for video or transcript.

I've promised myself I'll give WebWork2 a try "real soon now", but regardless I think we are probably tied to Struts and Tiles here due to the large amount of infrastructure and code invested into it by now.

Not that there is anything wrong with Struts! There certainly seems to be a lot of favourable comments for WebWork over Struts, but I still find I can churn new actions out nice and quickly, and don't tend to get too bogged down in repetitive form beans by reusing one across a sub-application and using validator to define all the rules on the input. Still, I can see where it can be cleaner, and maybe WebWork is the way to go.

Has anyone had a negative experience with WebWork2? That's something I'm yet to hear.

I'm impressed.

I haven't checked out JMeter for some time, although even when I did use it briefly about August last year for a large project's load testing requirements, it did the job.

The more recent versions have added a little polish, but now come with an ant task for automating the load test run and the server-side capacilities seem a lot clearer although I still haven't given them a try.

I think I'll be using it more often from now on, as automating such tests is a necessity, and its great to be able to test several components of your app in one platform (full web requests vs just the SQL you are running via the JDBC tests).

Add in a little functional testing by checking so pre and post conditions and you've got a reasonable solution. Considering we've used a commercial product with which I no longer have any confidence in its consistency or results, I'm really impressed with JMeter.

One thing though, the "add component" interface and the open/save model needs a serious redesign. Probably my only complaint a year ago and it is still there. File open does an import, and save does a subtree export. This is fine, but really it needs a workspace open/save option that is the default, and adding bits into the work space under separate test plans needs to be easier. I think it is possible under the current interface, but its certainly unclear. But this is only a minor complaint, because once it is setup you rarely worry about it.