How tomcat is able to locate a class that is not part of any of the jars in app libs

Question

In our application(applet) I want to enable export functionality if one of the required jars is found. I do not want to add this jar applet references to avoid download size.

I am using Class.forName with one of the classed to check whether particular is available. In local machine Class.forName call retruns an instance although the jar is not in any of the class paths.

Can anybody explain tomcat class discovery mechanism.

Answer 1

Based on your description of having an Applet I don't see any option but to include the jar file in the applet tag as the applet runs on the client side.

You could set HTTP cache headers for the jar files to allow the client browser to cache them, therefore, you only pay the download cost only once.

For frequently changing jar files include the a version number in the jar file name to avoid client side caching issues with same named but contentually different jars.

Edit: Although the question is about the way tomcat discovers the jars I think the root cause of the problem is elsewhere.

In Tomcat 6 on the server side Tomcat searches the $TOMCAT_HOME/lib and WEB-INF/lib directories for your jar files. If you add or remove files there you usually need to restart the entire Tomcat instance.

Edit2:

Your experience about locating the jar file might be because you run the HTML page from the same directory where your webapp resides or you have the JAR file in a common place or common classpath location (for example in the JRE/lib/ext directory).

Answer 2

I am having a hard time following your question. Are you trying to download classes into an applet if a particular runtime condition is met? From 6u10 I believe you could dynamically download extensions with DownloadService. Going back to 1.2, you can use URLCLassLoader.newInstance, although that wont be so good on the cache side of things.

Answer 3

Applets run at the client side(inside the browser of the user) not on the Tomcat web server, so this is unrelated to Tomcat.

You'd want to investigate how Applet classloaders work.

Usually they will try to downloading the classes from the web server under the same Url as the applet was fetched from. So if the applet is at http://www.example.com/Hello/HelloApplet and needs the class foo.bar.MyClass it will try to download http://www.example.com/Hello/foo/bar/MyClass.class if it isn't found locally.

Answer 4

This question isn't very clear. Tomcat and Applets are completely different in terms of class loading. Applets have a security manager that prevents certain things, such as loading arbitrary classes. They have to download the classes from the web server. The web server doesn't have to be tomcat or even Java; the applet files are just files served over plain HTTP.

As for Tomcat, this article explains version 6's classloading. In particular, Tomcat uses a heirarchy of classloaders to find classes. There are several well-known locations where jars are automatically loaded, such as $CATALINA_HOME/lib or $CATALINA_HOME/shared/lib. It also loads the web-app's own jars and classes. The classloaders work as follows:

1. The bootstrap class loader looks in the core Java classes folders.
2. The system class loader looks in the $CATALINA_HOME/bin/bootstrap.jar and
3. $CATALINA_HOME/bin/tomcat-juli.jar
4. The WebAppX class loader looks in WEB-INF/classes and then WEB-INF/lib
5. The common class loader looks in $CATALINA_HOME/lib folder.
6. The shared class loader looks in $CATALINA_HOME/shared/classes and $CATALINA_HOME/shared/lib if the shared.loader property is set in conf/catalina.properties file.

Answer 5

Reason: One of the other libraries(jars) referenced earlier had the class I was looking for.