Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: DO NOT REPLY [Bug 31883]  -     Better JNI support
Date: Mon, 25 Oct 2004 20:46:44 -0400
Message-ID: <E95FD77F0171D14DA1EEE0A785E92B430D38BB@mail3.basistech.net>
Thread-Topic: DO NOT REPLY [Bug 31883]  -     Better JNI support
Thread-Index: AcS6wUcwd2seT9j6Tt63KhAP1GBl7gAMxBlg
From: "Benson Margulies" <bim2004@basistech.com>
To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>

I'm supporting a number of JNI-related things in Tomcat, and I just
don't see the point of this idea.

A JNI class is inevitably a per-JVM resource. Giving a web-app a
backdoor way to push the classes up to the common level seems like a
security problem. What if two webapps try to load dueling versions of
some JNI?

My solution here has been to work with the J2EE JNDI support. I load the
classes in common\lib, and I have bean classes that manage the resource.
This requires tomcat-specific configuration.

Perhaps there would be more appetite for a discussion of a feature to
make it easier to manage 'common' classes. This might also be purely
bloatesque.

I'd love to be able to package up some JAR files, the information for
the global JNDI resources, and the ResourceLink for the default context
in a lump. As it is, I have to give customers a rather elaborate set of
instructions. Or an application that automagically edits xml files..


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org