Redeployment and hot deployment note

I. Reloadable)

A Web container usually has a special directory (for example, "webapps" in Tomcat and "deploy" in JBoss), which is regularly scanned, to find out the changes to new Web applications or existing applications. When the scanner detects that a deployed. War application is updated, the scanner triggers a redeployment process.
An additional feature supported by most web containers is the so-called "exploded deployment", also known as "non-packaged" or "directory" deployment. This method is not used to deploy one. you can deploy an archive file with. the war archive file has a directory with the same content layout. Because packaging a war file is a costly operation, deploying a directory can save a lot of building time. Unfortunately, even if you use directory deployment, you still cannot escape modifying a. Java file and wait for the entire application to be reinitialized. In most servers, any changes to the deployment descriptor or compiled classes will lead to a hot re-deployment.
To deploy a broken war or directory, You can omit this replication process by creating a symbolic link from a special directory to your project workspace.
If Maven is used, the expanded development settings in the workspace are complicated. If your application is a separate web application, you can use the jetty plug-in of Maven, which directly uses classes and resources from the Mave source and target project directory. Unfortunately, Maven's jetty plug-in does not support deploying multiple web applications, EJB modules, or ears. In the latter case, you will be stuck in the process of building artifacts.

Most Web containers prevent the loss of status information during redeployment by performing persistent operations on containers, that is, serializing all objects in the httpsession ing, then deserialize them in the new class loader.
Basically, they will copy all session states, which requires all session properties to be serializable (to ensure that session properties can be written to the database or files for future use ), this practice is not limited in most cases.
Session persistence has existed in most mainstream containers for many years (for example, restart persistence in Tomcat), but it is well known that this function is missing in versions earlier than glassfish V3.

In tomcat, it calls the standardcontext. Reload () method.
• The standardcontext. Reload () method is called.
• The previous webappclassloader instance was replaced by a new instance
• All references to servlet are discarded.
• The new servlet is created.
• The servlet. INIT () methods of these servlets are called.

 

 

Osgi is basically a set of modules. Each module is encapsulated in its own class loader, which can be discarded and recreated at will. When a collection is heavily damaged, these modules are initialized in the same way as Web applications. That is, the operations of each module are similar to those of Tomcat, which is a re-deployment task.

Recently, some Web frameworks, such as tapestry 5, rife, and grails, have adopted different practices by taking advantage of the fact that they already need to maintain the state of the application. They must ensure that the status is serializable. In addition, they must be easily re-created. In this way, after throwing away a class loader, there will be no need for re-initialization.
Because the lifecycle of a component is managed by the framework, it is easy to reconstruct the component in the new class loader without user intervention, in this way, the effects of code overloading are also created. In the background, the old component is destroyed (the class loader is discarded), and the new component is created (the class is read again in a new class loader ), the old status can be deserialized or created based on the configuration.

II. Hot deployment:

To solve the problem that modifying individual classes or configurations causes the whole application to be re-deployed, the following technologies are available:
Hotswap:
Hotswap: "hotswap" is a feature of JPDA (Java platform debugger Architecture). JPDA enhancements are newly added from Java 2 sdk1.4. Hotswap allows you to replace the class definition in JVM with the new class definition, which allows developers to replace the modified class with the old class in JVM during debugging without restarting the server. However, currently, hotswap only supports modification to the method body, and does not support modification to classes and method signatures (such as modifying class names, method names, and method parameters ). There is also a reason to consider these restrictions. Replacing the class definition requires an association between the new class and the old class. Here the association is the full name of the class (maybe there is other information ), if the class name is changed, you do not know which class to replace. The modification of the method signature should take into account the call of the running method and replace the existing method call with the method signature.

As mentioned above, hotswap has many limitations. To rely on IDE integration, you can only update the modification of the method body. You cannot create a method, add a domain, or even change the hierarchy of inheritance. This avoids the need to overload the container whenever a class bytecode is modified. A alternative solution for hotswap is jrebel.

Monitor the actually compiled. class files on the disk. Update the class whenever a file is updated.

Jrebel:

Unlike dynamic classloaders, [jrebel retains the identifiers and statuses of all existing objects and classes], allowing developers to continue using their applications without delay.

Note: Compared with hotswap, The myobject Pointer Points to the latest myobject. Class version.

 

Reference: http://article.yeeyan.org/view/213582/186226