Mozilla
I finally fixed the problem with mozilla-xremote-client. It ended up being associated with the Gnome preferred browser. Not sure how this setting was ever lost, but it's fixed now, and I can launch new Mozilla windows with impunity.

Now that Mozilla 1.7 provides access to all the editing widgets for Blogspot (including spelling) I'm finding that I'm pretty happy with it again. Though I'm still a little impatient for that Pango version! Any Linux users who don't know what I'm referring to, should give the 1.6 version a try.

Remote Resolver
Not a lot to report for today. The JUnit output logs indicated that a QueryException was being thrown from the Database class. I included a log statement just before this exception was thrown, so I could see what was happening. However, I didn't see anything come up in the logs. The line number of the thrown exception had changed accordingly, but the log was no where to be found, even though other logging statements from the same class were showing up.

It was only after abandoning this tack that I realised that the class was being run on both ends of an RMI connection. The log file I had was being generated at the server side of the connection, but the JUnit code that was failing was not generating a log at all. I finally got to see what I was looking for when I put my debugging log into a string and tacked it onto the end of the thrown exception. I should have done this much earlier, but sometimes a seemingly simple problem can entice you into spending more time on it than it is worth.

The problem ended up being due to the need to load a file into a model in order to have queryable data in it. This was done with the setModel SPI call which accepts URIs for the file to load and the model to insert into. My mistake was that the "file to be loaded" was not really that at all. Several weeks ago I'd asked "how do I load a file into one of these things?" and was told to use setModel, passing the URL of the file. I made the mistaken inference that this URL could only be for a file, where in fact it is for any model type at all. It wasn't all that long ago that this would have been right, but the resolvers were specifically written to make this kind of change, so I shouldn't have been surprised.

The Remote Resolver I'm testing had only registered that it can handle SOAP and RMI protocols (as these are the only remote protocols we support for the moment). There seemed to be no need to register any other protocol. But in order to load a file it also need to register that it can handle the "file" protocol. I suppose this makes sense in the more general case, as it will allow a user to use a resolver to query a file on a remote machine that has not yet been loaded into a model.

Of course, this was only the first step. I'm now trying to work out just why none of the tests are able to commit their queries. The problem is being caused by an exception that says: "Unable to get an appropriate session". I was able to see the code where this happens, but I've yet to determine why the correct type of session is not already available.

I may save myself some time if I ask AM for some more help. He wrote a lot of this framework, particularly the test framework, and his help today in working out my protocol issue was invaluable.