NetKernel + Kowari

Sadly, building a web application or service in Kowari kinda sucks. But, theoretically, Kowari is embeddable. So I set out to verify this assertion and to gain more knowledge about the inner workings of NetKernel.

On my road to discovery, I encountered a few issues only now partly resolved.

First, Kowari attempting to load a resource (config file) from it's own jar file failed. A call to ClassLoader.getSystemResource() was replaced by me with this.getClass().getClassLoader().getResource() to get by the failure.

Oddly this thread describes the same problem under Tomcat. But the suggestion posted does not work under NetKernel, namely Thread.currentThread().getContextClassLoader().getResource(CONFIG_PATH). But my workaround does not work under Tomcat. This may be a NetKernel issue. Thus far I've chosen to not formally lay blame.

Second, the JSR 173 libraries used by Kowari also fail due to ClassLoader issues. Moving them to the 'endorsed' classpath directory for NetKernel resolves the issue. Note the FactoryFinder class in the JSR implementation uses something rather funky, namely:

        try {
            // Construct the name of the concrete class to instantiate
            Class clazz = Class.forName(FactoryFinder.class.getName()
                                        + "$ClassLoaderFinderConcrete");
            ClassLoaderFinder clf = (ClassLoaderFinder) clazz.newInstance();
            classLoader = clf.getContextClassLoader();
        } catch (LinkageError le) {
            // Assume that we are running JDK 1.1, use the current ClassLoader
            classLoader = FactoryFinder.class.getClassLoader();
        } catch (ClassNotFoundException x) {
            // This case should not normally happen.  MS IE can throw this
            // instead of a LinkageError the second time Class.forName() is
            // called so assume that we are running JDK 1.1 and use the
            // current ClassLoader
            classLoader = FactoryFinder.class.getClassLoader();
...

Again I'll refrain from laying blame as the BEA guys have obviously put some thought into the issue.

Third, Kowari has no obvious (pre-built) way to stream their version of a ResultSet, called Answer, to XML. There is a BEEP related package with an answer streamer, but if failes on an XML BlankNode (something one would find very common in the wild). A fix for this was quite simple, yet I'm left with the nagging impression there is a better way.

Fourth, NetKernel is really just that, a kernel for managing the interaction and scheduling between components executing in the vm, called modules. But I haven't found support for explicit life-cycle management. That is, there is no init(), start() or stop() type methods on a module. It seems to rely on finalizers to clean up resources. Thus, shutting down a NetKernel instance corrupts the Kowari database.

Hopefully answers to my queries in their respective forums lead to code updates and answers so I can continue this. Would be nice to start work on the backend for a recent side project.

[11-16-04 - See update]