You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2004/10/25 20:34:52 UTC
DO NOT REPLY [Bug 31883] New: -
Better JNI support
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=31883>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=31883
Better JNI support
Summary: Better JNI support
Product: Tomcat 5
Version: 5.0.0
Platform: All
OS/Version: All
Status: NEW
Severity: Enhancement
Priority: Other
Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: junk@bbs.darktech.org
Hi,
Currently the only way to use JNI under Tomcat is to invoke System.loadLibrary()
outside the application. This is a documented release-note; it is also a
deployment nightmare.
I propose Tomcat provide a new mechanism whereby webapps can identify classes
loading libraries, and those classes can be instantiated from within a parent
classloader. The key is that we should be able to bundle these classes as part
of a deployment WAR file without having to deploy stuff into Tomcat's system
libraries directory. It would also be nice (although not strictly necessary at
this stage) to be able to detect all applications that make use of the native
class, so that one could unmount them all, replace the DLL, and remount them
all, without restarting all of Tomcat. If you want to get *really* fancy,
intercept all calls to System.loadLibrary() automatically, and use the
appropriate classloader on-the-fly without needing the user to explicitly point
out any classes.
This issue is meant to be a focus of discussion and fuel feedback from the
community.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org