The basic issue seems to be that part of the initialization sequence for logging is not finding a handler class.
The basic "fix" for this seems to be to arrange that the class for the handler be found in the initial application class path. This is what the "System" class path seems to mean (taken from the Javadocs for ClassLoader.getSystemClassLoader()). I noticed that the IBM Java loads this class slightly differently than the Java Jerry described. I didn't find a "spec" for this, so I suspect different Javas may load this in different ways. The IBM Java 5 uses the last non-system class loader on the call stack. This might be a fine distinction, coming into play only when loading from the "extensions" classes. A general solution with respect to using the bootstrap loader would be to not use the java -jar xxx form but instead use the java -cp xxxx org.apache.uima.bootstrap.UimaBootstrap etc. form, and put into the -cp classpath the uima-core jar, where the handler(s) are, along with the bootstrap jar. Another alternative would be to build the UimaBootstrap jar so that it included uimaj-core, or vice-versa. (I think that would work - but haven't test it). I'm not sure of all the implications of this, though. Putting the bootstrap class into uimaj-core, and setting the manifest to specify starting with the bootstrap, and then changing the start to java -jar uima-core.jar, is (in more detail) what Burn was suggesting below, I think. Both of these approaches put uimaj-core classes at the "root" level of the application (i.e., "System") class-loader chain. I can't think of any cases where that would not be OK; can anyone else? -Marshall Burn Lewis wrote: > Can we put the bootstrap class in uima-core so it will then have all those > classes in the system path. > > - Burn. > >
