Last said the class loader and its parent delegation model, referred to the same parents constrained delegation model is not a mandatory, but recommended to the class loader implementation of the developers, in java, most of the class loader We will respect this model, but there are exceptions, so far, parent delegation model was seen three times larger case "destroyed."
the first time:
Occurs before the parent delegation model appears, that before JDK1.2, because the parent delegation model was only introduced after JDK1.2, while the class loader and abstract classes java.Lang.ClassLoader the era in JDK1.0 already exist, the face of the user already exists from code that implements custom class loader, java designer to introduce parents had to make some compromises when you delegate model. For backward compatibility, java.Lang.ClassLoader after JDK1.2 added a new protected method findClass (), before that, the user is to override the loadClass () method, because when the virtual machine is loaded during class It calls the loader private methods loadClassInternal (), and the only logic of this method is to call your own loadClass ().
We also said before the code loadClass () method, specific logic parents delegated to achieve in this method, after JDK1.2 no longer advocate the user to override loadClass method, but his own class loading logic written findClass () method, logic loadClass () method, if the parent class loader fails, call your own findClass () method to finish loading, so that you can ensure that the new written class loader delegation model is a composite of both parents .
the second time:
This is a model of its own defects caused parents delegate can solve the problem of unified class basis of each class loader (the base of the upper classes loaded by the loader), it has become the foundation base class because they are always invoked as an API user code, but things are often not absolutely perfect, if the base class have to call back to the user code, then how to do it?
This is not impossible, a typical example is the JNDI service, java JNDI is now standard service, its code starts by the class loader to load (into them when JDK1.3 rt.jar), but JNDI purpose is to centralize management resources and look, he needs to implement and deploy the code to call JNDI provider Interface (SPI) in ClassPath applications from independent vendors, but the boot class loader can not know the code, that jdk is how to do it? They introduced: the thread context class loader (Thread Context ClassLoader). This class loader can be set by setContextClassLoader () method java.Lang.Thread class has not been set when you create a thread, he will inherit from a parent thread, if the global scope of the application have not been set, then , then this class loader is the default application class loader.
With the thread context class loader, you can do some "fraud" thing, JNDI service uses this thread context to load SPI code is required, which is the parent class loader request child class loader class loader to complete action this behavior has actually opened up what parents appoint a hierarchical model to reverse the use of the class loader, is contrary to the general principles have been combined with the parent delegation model, but also helpless. All the loading operation involving spi java in this way substantially all, e.g. JNDI, JDBC \ JCE \ JAXB JBI and the like.
the third time:
Is due yoghurt pursuit of dynamic process caused here that the "dynamic" refers to the current some very popular term, hot code replacement module hot deployment, it means you want the application can be like our computer peripherals as plug in a mouse, U disk without restarting the machine will be able to use the mouse in question on another mouse, you do not stop do not have to restart. For the personal computer to say, in fact, nothing restart once, but for some production systems, shutdown reboot may be classified as accidents, hot deployment there is great appeal in this case.
To say here is that OSGi, at first simply to understand what is OSGi, OSGI (Open Service Gateway Initiative, literally translated as "Open Service Gateway") defined in the latest OSGi Alliance OSGi given is The Dynamic Module System for Java, namely for Java dynamic modular system.
(Picture from the network)
The key to its modular hot deployment is to achieve its custom class loader mechanism, each program module (referred to in OSGi Bundle) has its own class loader, when you need to replace a Bundlle, put Bundle replaced even with the same heat loader alternative implementation code.
Here we describe a simple process received an OSGi class loading request
1. will be java. * At the beginning of class delegate to the parent class loader loads.
2. Otherwise, the class will be assigned within the list list delegated to the parent class loader loads
3. Otherwise, the Import list was delegated to Bundle Export class of this class of class loader.
4. Otherwise, find the current Bundle of ClassPath, uses its own class loader.
5. Otherwise, look for classes in their own Fragment Bundle whether, if in, then assigned to FragmentBundle class loader loads.
6. Otherwise, look Bundle Dynamic Import list, assigned to the corresponding Bundle class loader to load.
7. Otherwise, the class lookup fails
The above query sequence, although only beginning two o'clock parents delegate rules composite model, the rest of the class looks for are carried out at the same level of class loader in.
If you want to know more about OSGi, then here I am looking for articles, https://blog.51cto.com/9291927/2125230