Google is a great tool to be sure. If you’re looking for a restaurant, you can find out all about it. Want to know about the latest widget for cleaning tile grout? it’s probably there. But, as a programmer, for most of the things I need, it’s a huge disappointment.

One of the reasons I started this blog is that I tend to encounter very specific errors that usually have simple fixes but that can prevent me from progressing for days. Even more annoying, they’re the sort of problems that people encounter and fix every day. So I decided to document all the little annoying bugs I encounter along with their solutions so that others can find them using their search engine of choice. It works. I get hits all the time. My most popular post was one describing how to get Ubuntu running on a VIA micro-ATX server. I’m not the only one who sees these issues.

So here’s my issue with Google. When I encounter an error message, the first thing I tend to do is a search on the message itself. Now Google tries to interpret this with context, which is good, but sometimes I just want an exact match of the string. So I go to the advanced options and specify that I want an exact match. Google does one of two things:

It ignores me. It returns a whole raft of results that can in no possible way contain the string I’m looking for.

It returns a list of items that it says contain the string, but don’t. Often, as in case 1, they never could have. Sometimes the synopsis contains the string, but the link is totally unrelated. “Fine”, says I. “The page has probably just been updated.” So I check the cache. Nope. Never matched and never will.

This is not an isolated thing for me. I’ve experienced this many times over the last several months. It’s at a point where it’s less productive to use Google than to figure it out myself.

The problem is that I still have these brick walls with simple solutions that keep me from doing my real work until I get them fixed.

It occurs to me that I haven’t posted in a while, but I didn’t realize quite how long it’s been.

Since my last post, I’ve changed cities (and provinces), and started a new job leading a team of Java developers working on a critical enterprise application. I won’t name my employer because this blog isn’t about them. It is a great place to work though. They’ve kept me pretty busy so I haven’t worked on my own projects for a while, but that’s about to change.

Starting Monday, I have a week off. Like any good geek, that means I’ll have some time to work on my own projects. I have some updates to make to my ARM packages in Fedora, so I’ll start there. Then I’ll continue developing the QPP queuing model library, primarily because there’s some things I want to do with it, and because I have access to my reference materials again. I use queueing theory just enough to remember how much I’ve forgotten. So off we go!

Well, I’ve been trying all day to delete a record using entity beans. The SQL is simple. I could do it by hand in 3 lines, including related items. It’s easy in EJB too. All you have to do is remove the offending record from the collection. Except IT NEVER GOES AWAY! It will say it’s gone. And then when you requery the table, it’s still there. You can’t use the record manager to do it directly though. You have to remove it from the collection. And now we’ve come full circle and it still doesn’t work.

This should just work. Deleting a record is a simple, straight forward thing. There’s no hints in the documentation. There’s no debugging information. As with way too much EJB related it’s just trial and error. A lot of trials and a lot of errors, and many hours later I have no idea how to get this to work.

If I’d used JDBC, I would have been done about 8 hours ago. As it is, I have no idea.

At least Canada beat Russia in Olympic hockey tonight.

Oh, and for some unfathomable reason, JAX-WS exceptions can’t be serialized. But that’s a story for another day.

While the Geronimo update is a mixed bag, I’m pleased to say that updating to Google Web Toolkit (GWT) version 2.0 went a lot better.

In particular, the gwt-maven-plugin is a lot better than the last time I looked. Previously, I was unable to get it to work with my builds as its interface was completely different and it just plain didn’t work. They’ve since reconciled the interface and it works well with GWT 2.0.

The 32 bit machine built fine after I corrected some minor permission problems. The 64 bit machine tells a different story.

I’m having issues finding the EJB using JNDI. Basically, it’s unable to connect. The only references I can find to the error refer to Geronimo V1.0 and are 5 years old. I find it hard to believe that the product could have regressed that much, so it’s probably something in my configuration, but why would it build on one machine and not another?

I’ve been awfully boring lately from a blogging point of view. With Christmas and a whole bunch of other things on the go, I haven’t been putting as much time into development as I would have liked. Well, I’m now back at it.

First step is to install and test Geronimo V2.2 released in December. This is in progress and I should have more to say about it over the next couple of days. It will have to be installed on my local machine first, then on the continuum and test servers before deploying. Lets see what surprises it has in store!

These are known bugs as you’ll see if you search it, but finding proper workarounds has cost a lot of time.

The first issue I got was in using replaceregexp in an ant script called from maven. I’d added all the proper jars to the dependency lists, and specified the ant.regexp.regexpimpl property to use the org.apache.tools.ant.util.regexp.JakartaOroRegexp implementation, but ant was unable to find it. If I defined a new task for replaceregexp with the proper classpath, then the definition would work fine, but it was unable to find the JakartaOroRegexp class when it executed.

To solve this, I used the Java task to call ant instead of the ant task.

This worked well, but my ant script used native2ascii and I kept getting the message Error starting Sun's native2ascii. No matter how hard I tried to fix this in the script by modifying class paths, JAVA_HOME definitions and otherwise, the only way I could fix this was by creating a symbolic link from JRE_HOME/lib/ext to JDK_HOME/lib/tools.jar. This means I have to do this on every build machine, and I really shouldn’t have to. Of course, the bug shouldn’t exist in the first place, so I guess that’s life.

At least now I can move on to solving the problem I was originally trying to solve instead of wasting time getting the builds to work.

Well, it wasn’t all that clear to me after several reads of the documentation, but I worked around my Maven build issues using a fourth option. I have a pre-configured Geronimo server with all the pools created sitting idle and load it in using the tag instead of an assemblies tag. This means I have to pre-configure all my build servers and test machines, but at least it works.

I hope the Geronimo folks address this in an upcoming release. Of course, I would also hope that I could build pre-configured custom assemblies.

I’ve been working on this problem for some time with varying degrees of success. My goal is to have continuous integration working for all the modules of the system, and Maven is well suited to this. For some of my modules, things work well. For example, for independent modules not using a database or other system facility. I’ve even got web services that use JNI building with success.

The problem child is the EJB module that uses the database. It depends on a database configuration that’s very easy to create using the console. This doesn’t work well for continuous integration, especially as modules are loaded and unloaded for testing. The standard Maven approach is to install an assembly, load the pieces you need to test, and unload when done. The standard assembly doesn’t include the database pool so that has to be set up separately. Maven doesn’t support this.

Option 1: Create a custom assembly.

For Geronimo 2.1.3, which I’ve been using, this fails. Period. It can’t be done. In order to include the modules I need, I consistently get in “IOException: HEAD full” error. 2.1.4 doesn’t give this error and builds an assembly, but it fails to start with a ClassNotFound error.

Option 2: Create and install plugins

This can be done, but Maven refuses to load them because the manifest is incomplete. I haven’t investigated this option fully, primarily because it annoys me that a plugin creator would create an unusable plugin.

Option 3: Create the pool in the deployment plan

When loading from Maven, it just says “Sorry, try again.” with no indication as to what the error is. I’m paraphrasing, but if you’ve done much work with maven you know what I’m talking about. Loading it using the deployer.jar fails because the MySQL .jar is missing. And there’s no way to load it. Well, I could load it into a custom assembly, but we’ve already covered that.

Summary:
I’m stumped. I’ve tried the recommended approaches and all the work arounds I can think of. Time for a nap.