While JZKit is a fine piece of computer science, and runs very nicely once it's properly configured, it can be rather unhelpful in the diagnostics it issues as you're trying to get it into that state. Since ZOOM-Java runs on top of JZKit, it also suffers from some of those problems.
This document exists to help you find your way through some of the problems that I encountered as I bludgeoned my way through to a working ZOOM-Java implementation.
When starting up a JZKit application, you may get a message like this:
Starting up log4j:WARN No appenders could be found for logger (Z3950Origin). log4j:WARN Please initialize the log4j system properly.
Although this bills itself as a warning, it's more serious than that: it prevents you from getting subsequent error messages so that - for example - the ZOOM test-client can fail to connect to its server (e.g. because the server's not running) and you'll get no indication that anything's wrong: the client will simply say that it found 0 records, and printed all 0 of them. (Concerning which, see below.)
The problem here is that you need to have a log4j.properties file on your classpath - the logging library uses this file as configuration, to tell it what kinds of messages to output, where to put them and how to format them. I've found that it works OK to use the file of that name from the classes directory of the JZKit distribution, though I have never bothered to figure out the details.
Early in the execution of JZKit applications, you may see a message like this:
1 [main] WARN com.k_int.codec.util.OIDRegConfigurator - Unable to find codec class : com.k_int.OpenRequest.isoill.gen.ILL_APDU_Delivery_Info.APDU_Delivery_Info_codec
It's anyone's guess why JZKit thinks it needs this class, especially as the string APDU_Delivery_Info_codec does not actually occur anywhere in the JZKit source. For what it's worth, ILL is an ISO standard, based on the same ASN.1 notation as Z39.50, for inter-library loans.
My best guess is that something in the low-level code is getting confused about which ASN.1-based standard it's trying to implement, and consequently trying to load a class that it doesn't need. In any case, my strategy with this warning is just to ignore it. Irritating but true.
You may see this:
2508 [Z3950 Search Thread localhost] WARN Z3950Origin - Init was not OK, not sending outstanding queries, and failing those queries in the queue Found 0 records Printed all 0 records
This is JZKit's rather idiosyncratic method of reporting that there's no server listening on the specified address, and that the connection was therefore refused. You'd have to say that it can't be right to go ahead and claim to have ``found 0 records'', so there's some work to be done in the JZKit guts here. But you can fix this problem just my making sure your server is running.
If you see this -
Exception in thread "main" java.lang.NoClassDefFoundError: org/w3c/dom/Node at com.k_int.z3950.IRClient.Z3950SearchTask.processRecords (Z3950SearchTask.java:345)
The solution - duh! - is to make sure that you have the DOM classes on your classpath. Poking around on my system, I couldn't find any JAR files whose names were at all suggestive of the DOM, but in desperation I ran
which, rather disturbingly, showed me that something I had fourteen copies of the DOM classes in various JAR files lying around the place: six xalan.jars, five xerces.jars and one each of j2ee.jar, crimson.jar and xml-apis.jar. All but one of those fourteen, for what it's worth, were downloaded as parts of Knowledge Integration CVS archives :-) And the odd one out, crimson.jar, is part of Jakarta Ant which I only downloaded because I needed it to build JZKit!locate -i .jar | while read i; do echo === $i === unzip -l $i | grep -i org.w3c.dom done
Anyway, the obvious one to use is xml-apis.jar, which is distributed as a part of JZKit.
Exception in thread "main" javax.xml.parsers.FactoryConfigurationError: Provider for javax.xml.parsers.DocumentBuilderFactory cannot be found at javax.xml.parsers.DocumentBuilderFactory.newInstance(Unknown Source)
I have no idea what this means, but putting xalan.jar on the classpath seems to fix it.