-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Chuck,
On 5/23/13 12:01 PM, Caldarale, Charles R wrote: >> From: Christopher Schultz [mailto:ch...@christopherschultz.net] >> Subject: Re: Follow-up: Possible false-postive with >> JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and >> OracleTimeoutPollingThread > >> Thanks for the pedantry: I was in fact ignoring the difference >> between the system and boot ClassLoaders. However, the primordial >> ClassLoader does in fact exist, and does in fact load classes, >> and is not called the "boot" ClassLoader. > > What you're calling the primordial class loader _is_ the boot > class loader, identified by a null reference. (The use of > "primordial" in the page you referred to is unusual; it's known as > the boot or bootstrap class loader in almost all other > documentation.) It's responsible for more than just the java.* > packages, since it also loads all the com.sun.*, sun.*, and other > JVM-vendor supplied classes. I ignored the extensions class > loader, since it's rarely used and was not pertinent to the topic. While I haven't exactly implemented my own JVM or anything like that, I have often heard the boot class loader referred to as the primordial class loader. Either way, we're talking about the same thing. >> the system class loader is represented by an "ExtClassLoader". >> On top of that is an AppClassLoader. > > What you're looking at is JVM-internal classes (hence the $ in the > names), that just happen to be the ones chosen in current versions > of the JVM. The name is an implementation detail; the internal > class mechanism is used to handle privilege issues. The internal > names should not be construed as descriptive of the class loader > hierarchy. I wasn't inferring anything from the names of the ClassLoader objects: just showing what the hierarchy was given the code I wrote. >> On top of that is an AppClassLoader. > > Only for programs that supply their own, such as Tomcat. My > comments concerned the JVM itself, not Tomcat. Er, I meant that the "AppClassLoader" (an Oracle-specific thing) was in the hierarchy. The hierarchy I was showing was what actually happens when I run that example class from the command-line, so Tomcat isn't involved. Oracle's JVM has 2 ClassLoader objects between my class and the boot class loader. Presumably one of them is for loading extensions (ExtClassLoader) and then the other (Oracle's AppClassLoader) loads stuff from the CLASSPATH (or -classpath or java.class.path). When placing a JAR file into one of the paths found in java.ext.dirs, the parent ClassLoader for those classes ends up being Oracle's ExtClassLoader -- just "underneath" the ClassLoader that manages the items on the java.class.path. When I modified java.endorsed.dirs, the classes loaded from those directories were loaded by the primordial/boot class loader. Interesting. I would have expected a layer between them, but I guess it makes sense as you have to be able to override things like org.xml.*, etc. So, at least in Oracle's JVM: java.endorsed.dirs -> boot class loader (null) java.ext.dirs -> another class loader (ExtClassLoader) java.class.path -> a third class loader (AppClassLoader) (In that order: most user classes will start at the bottom and search upwards.) - From within Tomcat, of course, there will be a longer chain from webapp-loaded classes up to the top. >> DriverManager's ClassLoader is in fact null, the primordial class >> loader. > > Unless one configures a replacement DriverManager (I think there's > a system property for that, but I'm not sure). +1 ...but who uses DriverManager anymore, anyway? - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRnpSbAAoJEBzwKT+lPKRYoP0QALrFCAJuCVfCP4BHNLhyGu3F 7YvT1IFS7zSUZlKDf44vOqRfgvQoUdU+Lpj/LTjUxVTEzbvF+5W3LmmQ7Efo3bJd PA1Td2pqGJkUbcO7R1aSF2Xlaqzz9VzKvfjakenBq4MRzBCkzv06eNOoB+tEnyG1 uq+4CB5t4qS1kdEyZAI9wEPLK7wvHJFWZUk8s/NqK/X+rHA1yhzxWjWCOO+EjjZl 0TsQt44aVWhuL8X+goumQRfDkVjI0lpgOnhRQvnZo3b81H9zhhqvOzD9/JucOf+r PwuSRIOLlLloCq1sCSNXgG0YT4lkJsReYmXM8mMjSY8EEa7aTeqZQzLfM1AOLNI4 Wk+fCwHDBxpnBP70oKISVRvEFVgvn4nQIDK9JxVikT/p+QhY6CZU7vSzZMnTDPHP rXaJ2orhp4SIgb1Pr0VZ5RdLn785iEyxzqHVdONik+3XK/1azQ6JKe9TEEXXgVXS AFuuajDm2yJhsYFeYmsKbgAO5L30jxU3/YhgQ0toyYvPi8n11w4J4hjn9gB6WQ2s Rw+3nQ+25Jcww5sZ08nJdu+vcK/tWvjz6/B/vGrkpAilRZs5xxKAmwb4V+G5NiBs Fr3ph5Ys5kV03axHZRRxhjxqfF/GZdeAVHDc57//Vd0S9zuyZ1CWmXVqAJXfrnil fafc/jc6sAnd865xQ23X =w6CF -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
