Now you may ask yourself, "Why should I deal with multiple class loaders and their limitations and problems?" The short answer is that you probably have to, one way or the other. Even when you write a simple servlet or JSP program and deploy within a servlet container, your code is loaded by your very own class loader, preventing you from accessing other web applications' classes. In addition, many "container-type" applications such as J2EE servers, web containers, NetBeans, and others are using custom class loaders in order to limit the impact of classes provided by a component, and thus will have an impact on the developer of such components.Classloading is so important to Java EE that understanding classloading is one of the more important skills to have, after simple mastery of the APIs. Every application server has had its share of horror stories surrounding classloader issues - from JBoss, where one of the first pieces of advice to someone having problems is to make sure the classloader context is set, to WebSphere, which uses SPI to manage logging in the application server, so that deployed applications sometimes have to go to seemingly absurd measures to use a more recent version of a logging package. The choice of where to put various jars affects the entire server, because you might put a jar at a "higher classloader" level than you expect. The various versioning projects (OSGi, Spring-OSGi, JPF, JSR-277, among others) represent a need for implementation and understanding of custom classloaders. It's an excellent article, worth the time to read.
Andreas Schaefer has written "Inside Class Loaders" for OnJava, an article that exposes the Java classloader hierarchy clearly, illustrates why classloader knowledge is important, and finally, shows an example of an application with multiple classloaders. Considering that multiple classloaders is standard for Java EE, it's good knowledge to have.
Yes class loaders and class loading machanism is IMO extremly important for any senior Java programmer. Unfortunately the article doaesn't cover aspects of classloaders vis-a-vis protection domains and other security aspects. One of the interesting things that I ran into was related with JAAS. I developed a plug-in frmework for the company where I work where plug-in components are loaded of course by their own classloader instances (to allow later undeploy-ment). However attempting to use JAAS to authenticate on a group of plug-ins failed miserably. That's because JAAS uses classloader from the current thread (Thread.currentThread().getContextClassLoader()). The solution was a special classloader that augmented the usual class-loader policy ("vertical" classloading) with a "horizontal" classloading policy. It worked so nice and it still does. The point here is that classloaders are very powerfull things but they can also bring real pains if not used properly.
Sounds like a good reason to down load classpath helper. http://classpathhelper.sourceforge.net
Sounds like a good reason to down load classpath helper.Thanks for the link. I don't need it now but I'm sure I'll end up using it at some point.