Thanks Yoav for making the release!
Just a couple of minor nits on the release notes, $Id: RELEASE-NOTES,v
1.18 2004/06/15 18:42:06 yoavs Exp $
-
Tomcat 5.0 and JNI Based Applications:
-
Applications that require native libraries must ensure that the
libraries have
been loaded prior to use. Typically, this is done with a call like:
static {
System.loadLibrary(path-to-library-file);
}
in some class. However, the application must also ensure that the
library is
not loaded more than once. If the above code were placed in a class
inside
the web application (i.e. under /WEB-INF/classes or /WEB-INF/lib), and
the
application were reloaded, the loadLibrary() call would be attempted a
second
time.
To avoid this problem, place classes that load native libraries
outside of the
web application, and ensure that the loadLibrary() call is executed
only once
during the lifetime of a particular JVM.
Maybe give a hint on where to put them? TOMCAT_HOME/shared?
--
Tomcat 5.0 Standard APIs Available:
--
A standard installation of Tomcat 5 makes all of the following APIs
available
for use by web applications (by placing them in common/lib or
shared/lib):
Having this list here is a really good idea - thanks!
* ant.jar (Apache Ant 1.6 or later)
* commons-collections*.jar (Commons Collections 2.1 or later)
* commons-dbcp.jar (Commons DBCP 1.1 or later)
* commons-el.jar (Commons Expression Language 1.0)
...
* commons-el.jar (JSP 2.0 Expression Language)
commons-el.jar is in there twice, with different versions.
* naming-common.jar (JNDI Context implementation)
* naming-factory.jar (JNDI object factories for J2EE ENC support)
* naming-resources.jar (JNDI DirContext implementations)
* servlet-api.jar (Servlet 2.4 API)
You can make additional APIs available to all of your web applications
by
putting unpacked classes into a classes directory (not created by
default),
or by placing them in JAR files in the lib directory.
Where? Presumably under shared?
---
Web application reloading and static fields in shared libraries:
---
Some shared libraries (many are part of the JDK) keep references to
objects
instantiated by the web application. To avoid class loading related
problems
(ClassCastExceptions, messages indicating that the classloader
is stopped, etc.), the shared libraries state should be reinitialized.
Something which might help is to avoid putting classes which would be
referenced by a shared static field in the web application classloader,
and putting them in the shared classloader instead (JARs should be put
in the
lib folder, and classes should be put in the classes folder).
Again, more specific on where to put them - do you mean under
TOMCAT_HOME/shared/{lib,classes}?
JAVAC leaking memory:
The Java compiler leaks memory each time a class is compiled. Web
applications
containing hundreds of JSP files may as a result trigger out of memory
errors
once a significant number of pages have been accessed. The memory can
only be
freed by stopping Tomcat and then restarting it.
The JSP command line compiler (JSPC) can also be used to precompile
the JSPs.
Note: This issue has been fixed in Sun JDK 1.4.x.
Given that I think the large majority of the world uses 1.4 now, would
it maybe be better to say
Older versions of the Java compiler (pre-1.4.x) used to leak memory...
Maybe even recommend that they upgrade to 1.4 if possible (now that 1.5
/ 5.0 is almost upon us)?
---
Symlinking static resources:
---
By default, Unix symlinks will not work when used in a web application
to link
resources located outside the web application root directory.
This behavior is optional, and the allowLinking flag may be used to
disable
the check.
Again, where to put this? Of course it's the allowLinking attribute
of the Context element, but there
is a security issue with it; maybe refer them to read the discussion
under
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/context.html
before enabling it?
These are all minor nits, but each time we can clarify a detail like
this in the docco we might save a few postings
to the list that everybody would have to wade through...
Thanks again
Ian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
