Details of deploying a portlet in Liferay

Introduction:

Deploying a portlet in Liferay is far simpler than deploying a web application to tomcat. This article shows the secrets of this deployment.

For example, when we drop a war package of logsearchportlet in $ LIFERAY_HOME/deploy:

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/15463531P-0.png "title =" 21.png"/>

Analysis:

After this action occurs, it will be captured by the PortletAutoDeployerListener of the container, and thus enters the deploy () method:

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/1546356332-1.png "title =" 23.png"/>

We can see that the row 43rd will actually open this compressed file (logsearchportlet-1.1.3-SNAPSHOT.war) and then the comparator structure is the xml file structure of the portlet, because it meets, so we will execute here to the row 46th, in other words, our deployer uses the PortletAutoDeployer instance.

The next step will go to the 24th line, which encapsulates the details of deploying our war package with PortletAutoDeployer:

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/1546354T9-2.png "title =" 24.png"/>

It will delegate the deployFile (file, context) method of PortletAutoDeployer:

First, in row 712, it reads and writes the liferay-plugin-package.xml file in the war package:

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/1546352510-3.png "title =" 25.png"/>

The read content is stored in the instance of PluginPackage class, as follows:

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/154635C28-4.png "title =" 26.png"/>

Then, it checks the current war package version from pluginpackage in row 742nd to see if it is supported by the target Liferay container. If it is not supported, an exception is thrown:

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/1546352394-5.png "title =" 27.png"/>

This is obviously supported, so skip this Code:

Then, line 751-763 obtains the recommended context name from pluginPackage. Here we get the logsearchportlet, set it to the context attribute of pluginPackage, and finally update PluginPackage.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/154635HS-6.png "title =" 28.png"/>

Next we will construct the deployDir path of the deployment directory.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/154635NS-7.png "title =" 30.png"/>

As shown above, in row 765th, if displayName is not null, Add. war:

Then, we can further process the name of the deployment directory (deployDir) based on the server type:

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/15463530b-8.png "title =" 32.png"/>

It can be seen that if the appServer type is jboss, but we are not jboss, but tomcat, and our unpackWar is true (indicating that we want to open this war package ), therefore, the deployment directory removes the last four characters based on the deployDir path. the war is removed, so before the first row, the values of deployDir and displayName are the same, because they are added. war is removed. war.

Therefore, before loading the relative path of the deployment directory in the target Directory deployed in Row 3, we can obtain the absolute path of the deployment Directory, which is indeed consistent with our expectation.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/1546352E1-9.png "title =" 33.png"/>

Next, we construct a File object pointing to the deployment directory in row 788, and then generate and copy the File.

DeployFile will be called to deploy the war package to the specified deployment directory just generated:

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/1546355439-10.png "title =" 34.png"/>

Let's take a look at its implementation;

Aside from some unimportant things, we can directly jump to the 883rd line of deployFile. First, we can find that it created a temporary directory with a timestamp as the file name under the $ CATALINA_HOME/temp directory, this directory is used for the temporary directory of the deployment process, and then in line 887, expand our war file to this temp directory:

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/1546352117-11.png "title =" 35.png"/>

When 887 rows are called, the server prints a log indicating that the expanded io operation is in progress.

Expanding xxx into xxx/temp/<timestamp>

Then, in row 888th, we call the deployDirectory method to complete the specific deployment directory method,This step is very complicated. I will introduce it in detail in the following article.In general, the role is to add the specified file and configuration to the deployment directory:

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/15463555V-12.png "title =" 36.png"/>

In the last row, delete the temporary directory, and the whole process is complete.

Summary:

Here we are standing at the height of 1000 feet. We have made a rough analysis of the process after the war package is thrown to the $ CATALINA_HOME/deploy directory. In general, the following details occur:

(1) This event is captured by PortletAutoDeployerListener and enters the deploy () method.

(2) then select the appropriate deployer for the war package. It will open a Zip stream to read the war package and check its structure because the war package has a portlet. xml file, so it will let PortletAutoDeployer act as its deployer.

(3) When PortletAutoDeployer calls the deployFile () method to deploy this war package, it first reads the lifery-plugin-package.xml file, check whether the version of the war package is supported by the current target Liferay server. If not, stop the deployment and throw an exception. If yes, continue.

(4) Next, the main task is to create a deployment directory deployDir string. Its starting value is added after the displayName of the portlet. war. then it will determine the server type, and then select further processing for deployDir. If it is a tomcat server and undeployWar is set to true, it will be followed. remove war. Finally, convert the current relative deployDir to the deployDir of the absolute path.

(5) then it generates a File object pointing to the deployDir of the absolute path just now, and calls the deployFile () method to deploy our war package to the deployDir deployment directory generated by the steel mill in step 1, this method will first create a temporary directory for the deployment process under $ CATALINA_HOME/temp with the current timestamp as the file name, and then expand the deployed war package to this temporary directory, call the deployDirectory method to process the files in the temporary directory, and drop the files to the deployDir directory. Finally, delete the temporary directory.

The most interesting part here is the details of copying the content in the temporary directory of deployDirectory to the final deployment directory after processing, because it is too complicated, so I want to use a new article for analysis.

This article from "parallel line cohesion" blog, please be sure to keep this source http://supercharles888.blog.51cto.com/609344/1286593