This documentation is for WSO2 Carbon 4.4.1. View documentation for the latest release.
Page Comparison - Creating and Deploying Carbon Applications (v.3 vs v.4) - Carbon 4.3.0 - WSO2 Documentation
Due to a known issue do not use JDK1.8.0_151 with WSO2 products. Use JDK 1.8.0_144 until JDK 1.8.0_162-ea is released.

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Code Block
package org.wso2.carbon.application.deployer.webapp
 
/**
*  Check the artifact type and if it is a WAR, copy it to the WAR deployment hot folder
*/
 
List<Artifact.Dependency> artifacts = carbonApp.getAppConfig().getApplicationArtifact().getDependencies();
 
// loop through all artifacts and deploy them iteratively
	for (Artifact.Dependency dep : artifacts) {
	Deployer deployer;
	Artifact artifact = dep.getArtifact();
	if (artifact == null) {
		continue;
	}
 
/**
* for each service type, select the correct deployer
* for this we need to provide the relevent deployment directory on carbon server and the extension of the artifact
* these details are read from the configurations for the corresponding artifact type
* since webapps may have two artifact types we should get the correct deployer
*/
	if (WAR_TYPE.equals(artifact.getType())) {
		deployer = AppDeployerUtils.getArtifactDeployer(axisConfig, WAR_DIR, "war");
	} else if (JAX_WAR_TYPE.equals(artifact.getType())) {
		deployer = AppDeployerUtils.getArtifactDeployer(axisConfig, JAX_WAR_DIR, "war");
	} else {
		continue;
	}
 
	// once the deployer gets called we execute the webapp deployer to deploy
	if (deployer != null) {
		String fileName = artifact.getFiles().get(0).getName();
		String artifactPath = artifact.getExtractedPath() + File.separator + fileName;  
	// extracted path is our artifact extracted temp location. These details are available is the artifact
	try {
		// deploy the artifact 
		deployer.deploy(new DeploymentFileData(new File(artifactPath), deployer)); 
		// set the deployment state 
		artifact.setDeploymentStatus(AppDeployerConstants.DEPLOYMENT_STATUS_DEPLOYED);   
	} catch (DeploymentException e) {
		artifact.setDeploymentStatus(AppDeployerConstants.DEPLOYMENT_STATUS_FAILED);
	throw e;
	}
}

package org.wso2.carbon.application.deployer
 
/**
* Finds the correct deployer for the given directory and extension
*
* @param axisConfig - AxisConfiguration instance
* @param directory - Directory to retrieve the deployer
* @param extension - Extension of the deployable artifact
* @return Deployer instance
*
*/
public static Deployer getArtifactDeployer(AxisConfiguration axisConfig, String directory, String extension) {
	// access the deployment engine through axis config
	DeploymentEngine deploymentEngine = (DeploymentEngine) axisConfig.getConfigurator();
	// return the corresponding deployer to the required artifact type
	return deploymentEngine.getDeployer(directory, extension); 
}

Evolution in C-App deployment model

Prior to WSO2 Carbon 4.2.0 Turing platform release, the process of C-App deployment was different from the current approach. In the previous approach during C-App deployment, the CappDeployer initially extracts all the CAR files to the <PRODUCT_HOME>/temp directory. Thereafter, based on the artifact type, the CappDeployer will copy the C-Apps to relevant hot deployment folders in the <PRODUCT_HOME>/repository/deployment/server directory. Due to this approach the C-App deployment prior to the Carbon 4.2.0 era was not synchronous. One major drawback of this approach was during runtime, if an artifact failed during its deployment, there was no direct way to check as to which C-App deployed these faulty artifacts. In many production systems this requirement was crucial, since they tend to deploy dozens of C-Apps at once.

In current approach during C-App deployment, the CappDeployer initially extracts all the CAR files to the <PRODUCT_HOME>/repository/carbonapps/work directory. Thereafter, the CappDeployer copies the the artifacts based on the artifact type, to the <PRODUCT_HOME>/repository/deployment/server/carbonapps hot deployment directory. The DeployerSchedulerTask will run periodically to identify all changes in the hot deployment directories. If there are any changes (such as new C-Apps, edited C-Apps and deleted C-Apps) in the carbonapps hot deployment directory, the DeployerSchedulerTask will deploy the artifacts immediately. Thereby, this process is synchronous and atomic in the new C-App deployment strategy and if the CApp gets successfully deployed, we can guarantee that all the artifacts have been successfully deployed.