tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ian F.Darwin" <>
Subject Re: [ANN] Apache Jakarta Tomcat 5.0.28 Released
Date Sun, 29 Aug 2004 17:50:18 GMT
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 

> --------------------
> 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 
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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message