For the past week or so I've been working at untangling a hairball. The Wild5 site was our first product at bitBull, and it was a lot of fun to build. I worked with a team of great people who really know their stuff, and cut my teeth on a complex JSP/servlet/database site. Too bad it never made a cent.
James is still working on the games/graphics code which was used to create the chat, but the rest of us went off to other projects, and the site has languished. The live site is on a server we no longer have full access to, and some of the source code has fallen into the cracks (lesson: make sure everyone keeps their code updated in CVS!!) Every once and a while I get some time to take a whack at fixing some of the bits that have broken, in preparation for moving it to our own server, and each time I get a little further, although it always takes a while to figure out where I left off last time.
Since the wild5 was my first major Servlets project, it suffers from being a learning experience, there are lots of architectural flaws. It's not a total hack job, the HTML is created in JSP pages and the logic is mostly in separate libraries with well-defined functionality. But it's not totally consistent, there is still too much logic in JSP, the database and javax.servlet.* classes both creep into the logic, and of course there are zero unit tests, much less round-trip tests.
If I had the time and the possibility of revenue, I would do an overhaul using Good Programming ] techniques. First, write round-trip tests to parse the HTML and verify the functionality from the user's perspective, then start refactoring. Out with the JSP, in with Velocity, out with my half-baked persistence package, in with someting like OJB, unit testing all the way. But I don't, my objective is just to get it functioning on a new server.
The new and old servers are both Solaris, so the only real changes are the database, from Informix to MySQL, and the servlet engine, Resin to Tomcat 4. First I got it going on my Win2k laptop with MySQL, twiddling the SQL code to handle the database changes. This wasn't too painful, although my persistence package was only half-baked, we did keep most of the SQL code fairly centralized.
The biggest pain was when I humped it from my laptop onto the new Solaris box, it turns out MySQL is case sensitive on Unix, especially with respect to table names. Neither Informix on Unix nor MySQL on Windows is case sensitive, so until now the database code mixes capitalization for table names. Since our table names are often the same as names of classes and variables, a simple search and replace wouldn't do it. Ugh.
Now it's working, but I'm wrestling with Tomcat. I supposed I could leave it with Resin, but being a committer on Tomcat, even if I'm the world's least frequent contributor, I figure I ought to do the dogfood thing and run it. I'm currently stuck with an error I've seen before, where Tomcat finds all of the jars in WEB-INF/lib, and then declares that the path to each of them is invalid. I don't remember how I've fixed this before, I think it was something that didn't address the problem, e.g. update Tomcat from CVS and rebuild. The mailing lists and bug database mention the problem, but have no solution. I'll keep banging my head on it, maybe I'll be able to squash the bug.