Project page: 
Dossy 18nov2004: After much struggling trying to get the JNI channel working, I stumbled across this bug in the Apache Bugzilla database: JK2 documentation and usage issues (copy). It specifically speaks to running Tomcat 5/mod_jk2/Apache 2 in-process with JNI -- very applicable for anyone running AOLserver/Tomcat 5/nsjk2 in-process with JNI. In the Bugzilla report, there's a link to the Tomcat 4.1 JK2 documentation which isn't very well linked to.
Dossy 11nov2004: I have just checked in changes to nsjk2 to simplify the build process -- I'm still not done yet, but it's much better than it was before. Read the README.build file for step-by-step instructions on how to build nsjk2 and all the required pre-requisites.
NB. On Linux 2.4 kernel as of 3rd Oct 2004. You can't compile the CVS source for nsjk2 against APR 1.0.0. Even after changing the build scripts to point to APR-1 instead of APR-0. It does compile successfully against APR 0.9.4.
Also (missing for the build instructions) you need to symlink libaprutil-0.so to libaprutil.so as you do with libapr-0.so otherwise ant all fails.
Steve Manning (email@example.com)
There is a known bug in the Sun JVM 1.4 on Linux where it unnecessarily installs a SIGCHLD signal handler which interferes with Tcl's [exec] command. The bug has been fixed in JVM 1.5.0_beta2.
Date: Thu, 19 Aug 2004 15:34:04 -0400 From: Timothy Suh Subject: Re: nsjk2 - SEVERE error message.
There seems to be a bug with tomcat 5.0.27 specifically with tomcat-jni.jar package (see explanation below). I will report the bug to tomcat folks.
Solution is to use tomcat-5.0.19 which I know works. Other versions between 5.0.27 and 5.0.19 may also work if they do not contain the bug. I also tried replacing 5.0.27 with tomcat-jni.jar from 5.0.19. That worked too. Of course, not sure if tomcat will behave overall. But this is another option if you must use 5.0.27.
Boring explanation follows:
Basically, signature does not match. Looking at source code (MsgContext.java and ChannelSocket.java) for both 5.0.19 and 5.0.27, the problem is that
Public class ChannelSocket extends JkHandler ... MsgContext ep = new MsgContext() ep.setSource(this);
this is fine when
public final void setSource(JkHandler ch)
however you get NoSuchMethod error when
public final void setSource(JkChannel ch)
Date: Tue, 17 Aug 2004 15:34:32 -0400 From: Dossy Shiobara Subject: Change of ownership of the nsjk2 module
On August 6, there were some changes at AOL that folks may want to be aware of.
The first is that Mark Page has left AOL. We all wish him the best in his new gig. If we're lucky, maybe he'll still keep an eye on the project and poke around once in a while.
The second change is that Elizabeth Thomas has transitioned to a different group within AOL, and is no longer involved in AOLserver-specific development. Therefore, ownership of the nsjk2 module has been transferred to Timothy Suh.
Questions and issues should continue to be raised on this list or on the wiki, but in case folks want to contact someone directly, please redirect concerns to Tim's attention, now. Thanks!
Date: Fri, 21 May 2004 10:48:26 -0400 From: Elizabeth Thomas Subject: Re: AOLSERVER Java support in AOLserver
First off, I'm very excited about Dossy's new role. It's great news for the AOLserver project. I would also like to take this opportunity to introduce Timothy Suh, who is on our team here at AOL and is also working on nsjk2.
For the benefit of any newcomers, nsjk2 is a module which provides the ability to run the Tomcat servlet container with AOLserver (much like it is done with Apache). Tomcat can run either in the AOLserver process (recommended) or out-of-process. With nsjk2, you can have an AOLserver fielding requests for 'traditional' aolserver pages and as well as JSPs and servlets. Its javatclbridge utilities enable your java pages access to tcl and adp processing which allow you to leverage existing AOLserver-based infrastructure. As AOL has a large AOLserver-based investment, this bridging ability is a critical driver for our interest in nsjk2 for those projects which, for various reasons, choose a java-based implementation. This investment includes not only the services coded in ADP/TCL, but also our operational administration and configuration built around AOLserver. Strategically, the future of AOLserver/Tomcat is somewhat uncertain - it will simply depend on who finds it useful. However, there has been a great deal of interest in it here.
We are currently working on the following enhancements to nsjk2. These are driven from requirements of internal projects at AOL.
1. Tomcat 5 support
This is nearly done. In fact, if you check out the head of the CVS tree for nsjk2, you should be able to run nsjk2 with Tomcat 5. The main trunk is forming the basis for an upcoming v2 release.
For now, Tomcat 4 compatibility with only be supported on the (new) v1 branch (until such time that we can make v2 backward compatible). We will backport the new features described below to the v1 branch as well.
nsjk2_v1_r4 has been tagged (but not yet posted on sourceforge) - it consists of just a minor fix to the java NsLog bridge to automatically load the correct library.
2. Java-implemented tcl commands
We have a requirement to allow a tcl command to be implemented in java and available from the AOLserver tcl interps - this is particularly useful for administrative commands to be made available in the aolserver control port. This is not a full 'calling java from tcl' approach a la tclBlend, but more along the lines of how we implement tcl commands in C. The command is implemented in java, and exposed through creating a tcl command API. (Note that this does not prohibit future integration of tclBlend should someone be so motivated :) )
3. Java-controlled logging.
Tomcat and AOLserver have separate logging mechanisms, which is often undesirable to Operations, which wishes a single log (or single logging configuration mechanism). The existing NsLog class in the javatclbridge allows java code to log via the AOLserver Ns_Log mechanism. However, we have projects that wish to control all their logging on the Java side using facilities like log4j. To enable this, we are adding the ability in AOLserver for a module to 'take over' the Ns_Log functionality by registering callbacks.
The final completion of all these items is scheduled for late July, although you are likely to see them 'trickle in' to the baseline between now and then. In the process, we'll also be looking for and addressing issues that might affect AOLserver/Tomcat's viability in a production environment.
We are excited to hear about people's experiences with this combo and welcome any additional fixes/enhancements that others are able to contribute.