After a bit of wrangling, and a fair amount of useful feedback, I've achieved some success and have put the results here.
nk-mod-kowari is pretty basic, and probably doesn't work for whatever you would intend to do with it. It was the journey that matters.
On that journey, I got some good feedback from the NetKernel guys regarding life-cycle management of modules.
From Peter:
This philosophy is assisted by the NK/REST abstraction - whereby services generally don't hold state but instead state is usually transfered to a service with each request (ie true representation state transfer). The DB-accessor module is a clear example of this pattern - the configuration state is located at a URI reference - the service pulls that state back in each time a request is serviced. The NK Representation model and cache ensure that this is very efficient - though it is not immediately intuitive viewed from a traditional perspective.
No disagreement here, but i'm still getting bad vibes from Kowari on subsequent startups. I've even had the DB give me some soft of illegal state exception (sorry, no stack trace) that seems to have been resolved with a rm -rf of the datastore.
And Andrew had me take another look at the ItqlInterpreterBean. It actually returns an Element object, too bad it's not attached to a Document (nothing answer.getOwnerDocument().appendChild( answer ) won't fix).
Unfortunately I have only resolved this issue by manually editing the SessionFactoryFactory class in Kowari. As noted in my comments, the tomcat fix doesn't work for NetKernel.
The previous entry on NK and Kowari.
Leave a comment