Today, we are going to talk about class loader in the JavaEE environment. We start from the normal ClassLoader hierarchy in JavaSE application, then analyze the differences between JavaEE.
ClassLoader Hierarchy
In a normal JavaSE application, we have three levels of ClassLoader:
- Boostrap ClassLoader
- Extension ClassLoader
- System ClassLoader
Because all classes in Java are loaded by ClassLoader, we have to solve the problem: how is the first class in Java loaded? The answer is simple if we jump out of the scope of a single language.
The first class in Java is loaded by a c++ ClassLoader, and because its this functionality, it is called ‘Boostrap’ ClassLoader. Besides the first class, all the classes of Java core library are all loaded by this ClassLoader in the aim of security.
Extension ClassLoader, as it name indicates, is used to load installed extensions under lib/ext of jdk home.
System ClassLoader, on the other hand, is used to load application specific classes.
There exists father and son relationship between all of this three ClassLoader, which is called ‘ClassLoader Delegation Model’. In this model, when we need to load a class, father is always asked before son trying to load it. That means only when father ClassLoader fails to load a class, son ClassLoader then can try to do it. The major design choice here is security concern, in which JVM have to ensure the core library won’t be replaced by malicious code.
Bootstrap ClassLoader
^
| father
Extension ClassLoader
^
| father
System ClassLoaderJavaEE Classloader
Class loading in a web container, i.e. in a application server, is more complicated than a normal Java application. The normal configuration is that each web context (web application or WAR file) has its own ClassLoader, which has the System ClassLoader as its parent.
Bootstrap ClassLoader
^
| father
Extension ClassLoader
^
| father
System ClassLoader
^
| father
Web context ClassLoaderSuch a ClassLoader hierarchy is normal in Java, however the servlet specification complicates the hierarchy because it requires the following:
Classes contained within WEB-INF/lib or WEB-INF/classes have priority over classes on the parent ClassLoader. This is the opposite of the normal behaviour of a Java ClassLoader.
System classes such as java.lang.String are excluded from the webapp priority, and you may not replace them with classes in WEB-INF/lib or WEB-INF/ classes.
Translating what the specification says: the web context ClassLoader will not ask its father (the System ClassLoader, which loads the classes of application server) if it is going to load JavaEE classes, including classes of various library, classes of web applications etc. This requires the application server ClassLoader to add some special cases when loading classes.
What should be noticed is the specification does not clearly state what classes are System classes, and it is unclear if all javax classes should be treated as System classes. So the implementations of different application servers (e.g. jetty, tomcat) may have different loading priority of some classes, in which situation, we may find different behaviors because of class clash in WEB_INF/lib and normal classpath.
Furthermore, the following remind us another aspects that JavaEE ClassLoader needs to notice that cited from jetty doc:
Server implementation classes like Server should be hidden from the web application and should not be available in any ClassLoader. Unfortunately the specification does not state what classes are Server classes, and it is unclear if common libraries like the Xerces parser should be treated as Implementation classes.
Examples
The following is two questions we found that is related to this topic:
Ref
Written with StackEdit.
评论
发表评论