Migration - Other Considerations - Classloader Stragey
ClassloadeR stRategY The JEE specifications have traditionally had little to say about classloading strategy, an unfortunate omission that has led to many challenges in JEE portability. Implementers of the JEE specification have made autonomous decisions on the default class loading behavior for applications that they host, though most have recently made such behavior configurable. Still, the difference in the default behavior alone is enough to cause much confusion and require days, if not weeks, of troubleshooting in search of the culprit. For example a flat classloader model in JBoss can mean that two different web applications with the same class bundled in their library would actually share the same instance of that class. This is in contrast with the default classloader behavior in WebLogic where that identical class with load in two different classloaders would be considered two different classes. With JBoss, the static context between the two classes of the two web applications will be shared —whereas in WebLogic they are distinct. This is a significant behavioral difference that can have a large impact, but be difficult to trace. A related issue is the version mismatch of third-party libraries; applications often bundle the party libraries that are already shipped with the application server. However, depending on the classloading behavior, they may or may not actually be using their bundled version. It is easy to forget that with the exception of a few cases, “parent-first” is the most common classloader delegation strategy. This means that developers will often bundle a certain version of hibernate, struts, or other commonly used library and use it with a certain expected behavior, unaware that a different version embedded in the application server may actually be the one in effect, overriding the child classloader. This can cause issues resulting from subtle functional differences in various versions of libraries that can be hard to troubleshoot.