Thread.getcontextclassloader () Xiang Solution

A: This problem often occurs when you are writing framework code that requires dynamic loading of many classes and resources. Usually when you need to dynamically load resources, you have at least three ClassLoader you can choose to:²        the System class loader or call the Application class loader ClassLoader or application ClassLoader) ²        the current class loader ²         Current Thread class loader The problem above refers to the last kind of loader. What kind of loader is the right choice? The first option can easily be excluded: the System class loader (systems ClassLoader). This class loader handles class loading work under-classpath and can be invoked through the Classloader.getsystemclassloader () method. All static methods of Getsystemxxx () under ClassLoader are defined by this method. In your code, you should call this method as little as possible and use the other ClassLoader as proxies. Otherwise your code will work only in simple command-line applications, when the System class loader (systems ClassLoader) is the last class loader created by the JVM. Once you move your code to an EJB, Web application, or Java Web Start application, there's always a problem.       so let's look at the second option: the class loader in the current context. By definition, the current classloader is the loader of the class to which your current method belongs. This class loader is implicitly used when dynamic class.forname between Run-time classes, and when invoking a similar method such as Class.getResource (). It is also used by syntactic constructs like X.class class literals. The     thread context type loader was introduced on the Java 2 platform. Each thread has a class loader that corresponds to it (unless the thread is created by local code). This class loadsDevice is set through the Thread.setcontextclassloaser () method. If you do not call this method after thread construction, the thread inherits the corresponding context class loader from its parent thread. If you do not make any special settings for the entire application, all threads will be in the System class loader (systems ClassLoader) as their thread context class loader. Since the web and Java EE application servers have used the mature classloader mechanism to implement functions such as Jndi, thread pool, and component thermal deployment, this is rarely done without any thread class loader settings throughout the application.     Why does the thread-context class loader exist in such an important position? The introduction of this concept in J2SE is not noticeable. The reason many developers are puzzled by this concept is the lack of proper guidance and documentation in this regard by sun.     in fact, the context class loader provides a backdoor to the class loading mechanism, which is also introduced in J2SE. Typically, all classloader in the JVM are organized into hierarchical structures with a parent loader for each class loader (except the original class loader that boots the JVM). Whenever asked to load a class, the class loader first requests its parent class loader, which does its own class loading only when the parent class loader cannot load.    sometimes the sequential arrangement of such loads does not work, usually when the resources provided by the application developer must be dynamically loaded. Take Jndi as an example: its content (starting from j2se1.3) is implemented in the boot class in Rt.jar, but these jndi core classes need to dynamically load JNDI providers implemented by independent vendors and deployed under the classpath of the application. This situation requires a parent classloader (in this case, the boot class loader) to load a class that is visible to one of its child classloader (in this case, the system ClassLoader). The usual class loading agent mechanism does not implement this requirement. The solution (workaround) is to have the Jndi core class use the class loader for the current thread context, thus creating an effective way to reverse the basic class loading agent mechanism.     In addition, the above paragraph may remind you of something else: XML parsing java API (JAXP). Yes, when JAXP is just a j2se extension, it naturally uses the current class loader to boot the parser's implementation. And when Jaxp is added to the core class library of j2se1.4, its class load is changed toThe frontline class loader is completely similar to Jndi (and confusing to many programmers). Understand why I said that the guidance from sun was scarce?    after the introduction, let's look at the key issues: both of these options (the current ClassLoader and the current thread class loader) are not applicable in all environments. Some people think that the current thread class loader should be a new standard policy. However, when multiple threads interact through shared data, an extremely complex class loading screen is rendered, unless they all use the same context's classloader. Further, in some legacy solutions, the method of delegating to the current ClassLoader is already standard. For example, a direct call to Class.forName (String) (which is why I recommend trying to avoid invoking this method). Even if you try to invoke only the context-dependent classloader, there will still be some code out of your control. This uncontrolled class loading delegation mechanism is very dangerous to mingle with.     more serious problems, some application servers set the environment context and the current class loader to different instances of ClassLoader, which have the same classpath but do not have parent-child relationships in the delegation mechanism. Think about why it's so scary. Know that the class loader defines and loads a class instance with an ID number inside the JVM. If the current class loader loads an instance of class X, the instance calls Jndi lookup instance of Class Y, and the class loader of the context can also define the instance of load Class Y. The definition of this class Y is different from the definition of class Y as seen by the current ClassLoader. An exception is generated if a coercion type conversion is made.    This confusion will also exist in Java for some time. For those J2SE APIs that need to dynamically load resources, let's guess their class-plus strategy. For example,:ø         JNDI uses the thread context class loader ø          Class.getResource () and Class.forName () use the current class loader ø         JAXP (J2SE 1.4 and afterwards) using the thread context class loader ø        Java.util.ResourceBundle ø         URL protocol using the caller's current class loader handlers Specified via java.protocol.handler.pkgs system property are looked up in the bootstrap and system Classloaders Onlyø&nbs The p;        Java serialization API defaults to using the caller's current ClassLoader these classes and resource loading policy issues, which are certainly the most poorly documented part of the J2SE domain.