deployment Archive

Automating application deployment on Weblogic Server.

In this article we will demonstrate three ways of deployment and undeployment on Weblogic Server

1. Using WLST
2. Using JMX
3. Using build script.
Application Deployment using WLST


connect(‘weblogic’,’weblogic’,’t3://localhost:7001′)
edit()
startEdit()
deploy(‘CookieApp’,’D:/Replications/CookieApp’,targets=’AdminServer’)
save()
activate()
exit()

Application Undeployment using WLST

connect(‘weblogic’,’weblogic’,’t3://localhost:7001′)
edit()
startEdit()
undeploy(‘CookieApp’)
save()
activate()
exit()

Application Deployment using JMX


import java.io.*;
import weblogic.deploy.api.tools.*;
import weblogic.deploy.api.spi .*;
import weblogic.deploy.api.spi.DeploymentOptions;
import javax.enterprise.deploy.spi.TargetModuleID;
import javax.enterprise.deploy.spi.status.ProgressObject;
import javax.enterprise.deploy.spi.status.DeploymentStatus;
import javax.enterprise.deploy.shared.ModuleType;
import javax.enterprise.deploy.spi.Target;
public class DeployUsingJMX
{
public static void main(String ar[]) throws Exception
{
String aLocation=”D:/Replications/CookieApp”;
String aName=”CookieApp”;
WebLogicDeploymentManager deployManager=SessionHelper.getRemoteDeploymentManager( “t3″,”localhost”,”7001″,”weblogic”,”weblogic”);
System.out.println(“\n\t WebLogicDeploymentManager: “+deployManager);
DeploymentOptions options = new DeploymentOptions();
System.out.println(“\n\t DeploymentOptions: “+options);
options.setName(aName);
Target targets[]=deployManager.getTargets();
int i=0;
for (i=0;i
{
System.out.println(“\n\t “+targets[i]);
}
Target deployTargets[]=new Target[1];
deployTargets[0]=targets[0];
System.out.println(“For test purpose we are deploying on Admin Server”+targets[0]);
ProgressObject processStatus=deployManager.distribute(deployTargets, new File(aLocation), null,options);
DeploymentStatus deploymentStatus=processStatus.getDeploymentStatus() ;
System.out.println(“deploymentStatus.getMessage(): “+deploymentStatus.getMessage() );
TargetModuleID[] targetModuleIDs=deployManager.getAvailableModules(ModuleType.WAR, deployTargets);
if(targetModuleIDs != null)
{
System.out.println(“\n\t targetModuleIDs [] = “+targetModuleIDs);
for (int j=0;j
{
System.out.println(“\n\t “+targetModuleIDs[j]);
deployManager.start(targetModuleIDs);
}
}
}
}

 

Application Un-Deployment using JMX

import java.io.*;
import weblogic.deploy.api.tools.*;
import weblogic.deploy.api.spi .*;
import weblogic.deploy.api.spi.DeploymentOptions;
import javax.enterprise.deploy.spi.TargetModuleID;
import javax.enterprise.deploy.spi.status.ProgressObject;
import javax.enterprise.deploy.spi.status.DeploymentStatus;
import javax.enterprise.deploy.shared.ModuleType;
import javax.enterprise.deploy.spi.Target;
public class UndeployUsingJMX
{
public static void main(String ar[]) throws Exception
{
WebLogicDeploymentManager deployManager=SessionHelper.getRemoteDeploymentManager(“t3″,”localhost”,”7001″,”weblogic”,”weblogic”);
System.out.println(“\n\t WebLogicDeploymentManager: “+deployManager);
DeploymentOptions options = new DeploymentOptions();
System.out.println(“\n\t DeploymentOptions: “+options);
TargetModuleID[] targetModuleIDs=deployManager.getAvailableModules(ModuleType.WAR, deployManager.getTargets());
if(targetModuleIDs != null)
{
System.out.println(“targetModuleIDs length: “+targetModuleIDs.length);
for(int i=0;i
{
System.out.println(“\n undeploying targetModuleIDs[“+i+”]: “+targetModuleIDs[i]);
ProgressObject processStatus=deployManager.undeploy(new TargetModuleID[]{targetModuleIDs[i]});
DeploymentStatus deploymentStatus=processStatus.getDeploymentStatus() ;
System.out.println(“deploymentStatus.getMessage(): “+deploymentStatus.getMessage() );
}
}
}
}

Application Deployment and Undeployment using ant wldeploy task.

<?xml version=”1.0″ encoding=”ISO-8859-1″ ?>

<project name=”DeploymentBuild” default=”all” basedir=”.”>

<property name=”wl.home” value=”C:/bea103/wlserver_10.3″ />
<property name=”deploy.name” value=”CookieApp” />
<property name=”deploy.source” value=”D:/Replications/CookieApp” />
<property name=”wls.username” value=”weblogic” />
<property name=”wls.password” value=”weblogic” />
<property name=”wls.hostname” value=”localhost” />
<property name=”wls.port” value=”7001″ />
<property name=”deploy.target” value=”AdminServer” />

<path id=”wlappc.classpath”>
<fileset dir=”${wl.home}/server/lib”>
<include name=”*.jar”/>
</fileset>
</path>

<taskdef name=”wldeploy” classpathref=”wlappc.classpath” classname=”weblogic.ant.taskdefs.management.WLDeploy”/>

<target name=”deploy”>
<wldeploy action=”deploy”
name=”${deploy.name}”
source=”${deploy.source}”
user=”${wls.username}”
nostage=”true”
password=”${wls.password}”
verbose=”true”
adminurl=”t3://${wls.hostname}:${wls.port}”
targets=”${deploy.target}” />
</target>

<target name=”undeploy”>
<wldeploy action=”undeploy”
name=”${deploy.name}”
user=”${wls.username}”
password=”${wls.password}”
verbose=”true”
adminurl=”t3://${wls.hostname}:${wls.port}”
targets=”${deploy.target}” />
</target>

</project><?xml version=”1.0″ encoding=”ISO-8859-1″ ?>

<project name=”DeploymentBuild” default=”all” basedir=”.”>

<property name=”wl.home” value=”C:/bea103/wlserver_10.3″ />
<property name=”deploy.name” value=”CookieApp” />
<property name=”deploy.source” value=”D:/Replications/CookieApp” />
<property name=”wls.username” value=”weblogic” />
<property name=”wls.password” value=”weblogic” />
<property name=”wls.hostname” value=”localhost” />
<property name=”wls.port” value=”7001″ />
<property name=”deploy.target” value=”AdminServer” />

<path id=”wlappc.classpath”>
<fileset dir=”${wl.home}/server/lib”>
<include name=”*.jar”/>
</fileset>
</path>

<taskdef name=”wldeploy” classpathref=”wlappc.classpath” classname=”weblogic.ant.taskdefs.management.WLDeploy”/>

<target name=”deploy”>
<wldeploy action=”deploy”
name=”${deploy.name}”
source=”${deploy.source}”
user=”${wls.username}”
nostage=”true”
password=”${wls.password}”
verbose=”true”
adminurl=”t3://${wls.hostname}:${wls.port}”
targets=”${deploy.target}” />
</target>

<target name=”undeploy”>
<wldeploy action=”undeploy”
name=”${deploy.name}”
user=”${wls.username}”
password=”${wls.password}”
verbose=”true”
adminurl=”t3://${wls.hostname}:${wls.port}”
targets=”${deploy.target}” />
</target>

</project>

 

References:-

http://download.oracle.com/docs/cd/E13222_01/wls/docs92/config_scripting/reference.html

weblogic.Deployer usage

Below article provides some sample usages of the weblogic.Deployer utility.

weblogic.Deployer is a Java-based deployment tool that provides administrators and developers command-line based deployment operations.

Deploy application on admin server:

java weblogic.Deployer -adminurl url -username username -password password -name myapp -deploy c:/myapps/myapp.ear

Deploy individual modules in application to different targets:

java weblogic.Deployer -adminurl url -username username -password password -name myapp -targets mywar@webserver,myjar@ejbserver -deploy c:/myapps/myapp.ear

Undeploy application from specified targets:

java weblogic.Deployer -adminurl url -username username -password password -name myapp -undeploy -targets server1,server2..

Redeploy application on current targets:

java weblogic.Deployer -adminurl url -username username -password password  -name myapp -redeploy

Redeploy individual module in an application:

java weblogic.Deployer -adminurl url -username username -password password -name myapp -redeploy -targets moduleA@serverA,moduleA@serverB

Partially redeploy, for example, to update a JSP in a exploded webapp:

java weblogic.Deployer -adminurl url -username username -password password -name myapp -redeploy mywar/index.jsp

The path of JSP to be updated is relative to the root of the  application. If a directory is specified the entire subtree is updated.

Multiple servers sharing the same physical deployment:

java weblogic.Deployer -adminurl url -username username -password password -name myapp -targets server1,server2 -nostage -deploy c:/myapps/myapp.ear

The -nostage option indicates that the application is available on all target servers at the same path and hence server should not copy files to the managed servers.

Deploy the first application version on admin server:

java weblogic.Deployer -adminurl url -username username -password password -name myapp -deploy c:/myapps/myapp_v1.ear

Perform Production Redeployment of a new application version on admin server:

java weblogic.Deployer -adminurl url -username username -password password -name myapp -redeploy -source c:/myapps/myapp_v2.ear

Note: The above feature is used for Side By Side deployment strategies ideally preferred for production environments.

Refer the below article know more about Side By Side deployment.

http://weblogic-wonders.com/weblogic/2009/12/02/side-by-side-deploymentversioning/

Deploy application to administration mode on admin server:

java weblogic.Deployer -adminurl url -username username -password password -name myapp -deploy c:/myapps/myapp.ear -adminmode

Note: The above feature is ideally used for sanity testing so that the application can process only admin requests.

Transition application from administration mode to running on admin server:

java weblogic.Deployer -adminurl url -username username -password password  -name myapp -start

Transition application from running to administration mode on admin server:

java weblogic.Deployer -adminurl url -username username -password password  -name myapp -stop -adminmode

Deploy a library on admin server:

java weblogic.Deployer -adminurl url -username username -password password -name mylib -library -libspecver 1.0 -libimplver 2.0 -deploy c:/myapps/mylib.jar

Note: This feature would deploy the file as library rather than as an application.

Deploy an application on admin server with a deployment plan:

java weblogic.Deployer -adminurl url -username username -password password  -plan c:/myapps/myapp/plan/plan.xml -deploy c:/myapps/myapp/app/myapp.jar

Note: The above feature uses plan.xml to help administrators easily change an application’s WebLogic Server configuration for a specific environment without modifying existing Java EE or WebLogic-specific deployment descriptors.

Refer the below article for a sample usage of plan.xml

http://weblogic-wonders.com/weblogic/2009/11/29/plan-xml-usage-for-message-driven-bean/

Update an application configuration:

java weblogic.Deployer -adminurl url -username username -password password -plan c:/myapps/myapp/plan/newplan.xml -name myapp -update

Deploy a queue to a specific JMS server:

java weblogic.Deployer -adminurl url -username username -password password -submoduletargets myqueue@myjmsmodule@JMSServer -deploy c:/myapps/myapp/app/myapp.ear

For documentation on weblogic.Deployer refer the below link:-

http://download.oracle.com/docs/cd/E14571_01/web.1111/e13702/wldeployer.htm

For trouble shooting deployment issues refer the below article.

http://weblogic-wonders.com/weblogic/2010/11/30/deployment-issues-on-weblogic-server/

Note: In the above examples we are specifying the username and password in plain text format and that could cause a  security issue.

You can use the STOREUSERCONFIG feature of the weblogic.Admin utility which generates userconfig file and userkey file containing an encrypted username and password.

Refer the below article for more information on userconfig and  userkey files.

http://weblogic-wonders.com/weblogic/2009/11/30/steps-to-use-userconfig-file-and-userkey-file/

For example, deploying an ear file using the userConfigFile feature is below.

java weblogic.Deployer -userconfigfile C:/bea103/storeconfig/config-file -userkeyfile C:/bea103/storeconfig/keyfile -name myapp -targets MS1,MS2 -deploy  C:/myapps/myapp.ear

Best Regards,

Wonders Team. 🙂

Stage Mode of Deployment in Weblogic Server

In Stage Mode of Deployment, the application is copied over to the stage directory of the target servers. By default the stage folder is present in the root directory of the server. This mode of deployment is generally used when the application size is not huge.

These are the Steps
Step 1 ). Transfer the War file to the Admin Box in a specific directory.

$ pwd
/users/faisal/app

$ ls
HighCPU.war

Step 2 ). Set the Environment.

. ./setWLSEnv.sh

NOTE: While running the above script please use two DOTs like mentioned above. The first DOT represents that set the Environment in the Current Shell and the second DOT (./) Slash represents that pick up the Script from the current Location. Both DOTs are separated by a single space. Once u run “. ./setWLSEnv.sh” after that try to echo the values of $CLASSPATH and $PATH

Step 3 ). Executed the command line weblogic.Deployer command to deploy the application on the cluster Cluster.

$ java weblogic.Deployer -adminurl t3://localhost:7001 -user weblogic -password weblogic -name HighCPU -stage -targets Cluster -deploy HighCPU.war
weblogic.Deployer invoked with options: -adminurl t3://localhost:7001 -user weblogic -name HighCPU -stage -targets Cluster -deploy HighCPU.war
<Jul 21, 2010 11:11:50 PM PDT> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiating deploy operation for application, HighCPU [archive:

/users/dba/oracle/app/HighCPU.war], to Cluster .>
Task 4 initiated: [Deployer:149026]deploy application HighCPU on Cluster.
Task 4 completed: [Deployer:149026]deploy application HighCPU on Cluster.
Target state: deploy completed on Cluster Cluster
The WAR file will be copied over to the stage folder of each Managed Server of the Cluster named Cluster.
/users/faisal/bea/user_projects/domains/test_domain/servers/MS1/stage

The Managed Servers will deploy the copy of the application present of their local stage folder.

If we have a look at the config.xml, we can see the staging-mode as stage.

<app-deployment>
<name>HighCPU</name>
<target>Cluster</target>
<module-type>war</module-type>
<source-path>/users/dba/oracle/app/HighCPU.war</source-path>
<security-dd-model>DDOnly</security-dd-model>
<staging-mode>stage</staging-mode>
</app-deployment>