Up until we brought in the suite of IBM Websphere tools and many of the developers migrated over to Rational Application Developer 6.0 (RAD), we were doing all deployments via ant. I confirmed last week that we’ve switched over in the last 9 months to almost complete reliance on building WARs or EARs from RAD via a right click on the project option.

I was reminded of the danger of this approach recently when on one project the tech lead was out on vacation and the other developer hadn’t been involved much in the setup of the project. It turned out we needed to create an EAR of the project instead of a WAR so our sysadmins could deploy the application. It didn’t need to be an EAR because there were zero EJBs involved, but that was the hard requirement.

Anyway next problem turned out to be we needed to rename the EAR file created by RAD. Turns out it relies on the name of the RAD project and you can’t actually change the name of the EAR file generated. To change it you have to change the name of the project. Since this is checked into CVS that would result in a top level directory name change. We tried a few workarounds, but the problem wasn’t resolved until a day later when the developer came back from vacation.

Just a small warning that it can be very easy to fall into some reliance on a tool and end up in these sorts of situations. The fix is luckily pretty easy as well.

• Require ant or maven build files.
• Add projects to cruisecontrol within the first day or two and include a deployment target. (Actual deployment may be harder as we don’t have a license to run Websphere on our build box.)
• Test that any developer can checkout a project and deploy the project without any reliance on RAD.

I’m going through installing MySQL 5.0 on my G5 iMac so I can progress through the Agile Web Development with Rails book. One of my brothers is going though it and wants to bounce issues off me as he comes across them. Anyway I knew the installer had gotten very easy and that it included a control panel in the System Preferences, but now there’s a GUI Administrator tool as well, nice.

After 23 days into the first Sprint on one of my teams projects, I finally got a very rewarding email from Cruisecontrol with the following message:

Unit Tests: (89)
All Tests Passed

The comment on the CVS file,

, was simply:

first test cases

The back story is I had been charting the unit tests for the project for the past few days showing a very static 85 unit tests. I had even taken to posting updates on the wall with a flat line of bar graphs pointing out the obvious. The 85 unit tests don’t sound to bad, but they were inherited from an earlier codebase that was being used. All the new code for the Sprint was completely untested.

The project is on a first Sprint and has had the usual sorts of issues:

• One developer with one past JSF project and one developer with only two past Struts projects.
• Multiple strange problems with JSF 1.0.
• Connectivity issues to our legacy system.
• Websphere configuration issues with deployments and classloaders.
• RAD 6.0 crashing a few times per day.
• Not hooked up to Cruisecontrol until about day 16 of the Sprint.

And as usual fixing all of these problems trumped writing tests. So even though it’s the first tests written on the project and they’re ‘test later’ unit tests, it’s still a great sign of progress. For the developer who checked in the tests today they’re his first unit tests written in production code.

As a small bit of gratitude and encouragement I delivered two well deserved Hershey’s bars to the developers around lunch time. Progress to TDD is slow, but there is progress.

I signed up for a free one project account for Basecamp today and setup a small project for my company’s core values committee. So far it seems really nice, easy collaboration with a small team. The real test will come over the next few weeks if it actually gets used. I love these sorts of things, but I don’t pretend that everyone gets into them. We may end up doing a lot of coordinating via email if the team isn’t ready for web collaboration.

We’ve turned on Java 2 security in our environment. Java 2 security is turned off on every app server by default including Websphere. This little setting caused us quite a few problems as we hadn’t built any of our applications with this in mind. My anecdotal experiences is that I’ve never seen it used anywhere, but that is just my experience.

Up until now we’ve been able to deal with the headaches. A nasty surprise was apparently using RAD and its built in test server you literally can’t turn it on without breaking your test portal instance. So we don’t try to run Java 2 Security on our local instances unless we don’t need portal. Today I learned about a new issue.

I’m working on our intranet portal project and I’ve noticed for a while that search hasn’t been enabled. As it turns out one of the developers showed me the issue with search. You can go to the admin portal for search to setup the crawler, and it needs to generate a unique URL. The problem appears to be since Java 2 Security is turned on all the generated unique URLs are really long (Possibly some encryption of the URL params?). No problem there except in the admin web page it truncates the URLs since the form field only allows 250 characters. We haven’t found a workaround yet, but we haven’t spent too much time digging.

Now I find out the latest version of Websphere Portal, 5.1 only just added Java 2 Security:

WebSphere Portal v5.1 offers a number of security enhancements and it now supports Java 2 Security. (link)

So we have a new question for our IBM lab advocate. Just how many customers of theirs actually enable Java 2 Security in Websphere Portal?