Deployments
Deployment an application involves the following tasks:
Preparing: Choosing weather to package the application as an archived file or keep in an exploded directory.
Configuring: Creating a deployment plan to maintain the configuration changes without changes the deployment descriptors.
Deploying: Targeting and distributing the application to servers in an OracleWebLogicServer domain.
Deploment Methods: WLS (WebLogic scripting) supports three types of deployment methods.
1. Auto-deployment
2. Console deployment
3. Command-line Deployment (WLST)
You can deploy:
1. Enterprise, Web, and EJB applications
2. Web services
3. J2EE libraries
4. JDBC, JMS and Diagnostic Framework modules
5. Resource adapters
6. Optional packages
7. Client application archives
Applications and EJBs can be deployed:
1. In an archived file(.ear, .war, .jar)
2. In an exploded(open)directory format
Deployment Tools: Several methods are available to deploy the Oracle WebLogic Server applications and shared libraries, including:
1. Administration console
2. Auto-deployment folder
3 WebLogic Scripting Tool(WLST)
Preparing: Choosing weather to package the application as an archived file or keep in an exploded directory.
Configuring: Creating a deployment plan to maintain the configuration changes without changes the deployment descriptors.
Deploying: Targeting and distributing the application to servers in an OracleWebLogicServer domain.
Deploment Methods: WLS (WebLogic scripting) supports three types of deployment methods.
1. Auto-deployment
2. Console deployment
3. Command-line Deployment (WLST)
You can deploy:
1. Enterprise, Web, and EJB applications
2. Web services
3. J2EE libraries
4. JDBC, JMS and Diagnostic Framework modules
5. Resource adapters
6. Optional packages
7. Client application archives
Applications and EJBs can be deployed:
1. In an archived file(.ear, .war, .jar)
2. In an exploded(open)directory format
Deployment Tools: Several methods are available to deploy the Oracle WebLogic Server applications and shared libraries, including:
1. Administration console
2. Auto-deployment folder
3 WebLogic Scripting Tool(WLST)
Admin Console Deployment: If we deploy an application in console deployment first we create domain and start the Admin server.
1 Click on Deployments
2: Click on Lock And Edit
3: Click on Install
1 Click on Deployments
2: Click on Lock And Edit
3: Click on Install
4: Select Location of the Application which we want to deploy
5: Click on Next
Here i have selected Calendar.war
I am providing some of the sample application which can be deployed in Weblogic.
6: Choose Targeting Style
Select Install this deployment as an application
The other type is Deploy as a library.If you do so then the other application which are deployed in the same domain can use that deployment in there application.
7: Click on Next
8: Select Deployment Targets
Admin server or Cluster
9: Click on Next
10: Select security rules and policies
Select DD only
Select Stage or No-Stage Mode
11: Click on Next
12: Click on Finish
13: Click on Activate Changes
Click on the Deployment and select the Application and click on start ==>Serving all request and then the application will become active.
Open a new tab and hit
http://localhost:7001/Calendar
the application will load .
If you have deployed on the Managed Server then change the port number and hit the application.
Auto-deployment
Auto-deployment is a method for quickly deploying an application to a stand-alone server (Administration Server) for evaluation or testing. It is recommended that this method be used only in a single-server development environment.
If auto-deployment is enabled, when an application is copied into the \auto-deploy directory of the Administration Server, the Administration Server detects the presence of the new application and deploys it automatically (if the Administration Server is running). If WebLogic Server is not running when you copy the application to the \auto-deploy directory, the application is deployed the next time the WebLogic Server Administration Server is started. Auto-deployment deploys only to the Administration Server.
You can run a WebLogic Server domain in two different modes: development and production. Only development mode allows you use the auto-deployment feature
Development mode enables a WebLogic Server instance to automatically deploy and update applications that are in the domain_name/auto-deploy directory (where domain_name is the name of a WebLogic Server domain).
Production mode disables the auto-deployment feature and prevents any applications you place in the auto-deploy directory after you switch to production mode from being deployed. When you switch from development mode to production mode, any applications that were previously deployed via the auto-deploy directory remain deployed; if you wish to undeploy or redeploy such applications after you have switched to production mode, you must undeploy or redeploy them manually (for instance, with the WebLogic. Deployer command and the -undeploy or -redeploy options, as described in WebLogic. Deployer Command-Line Reference).
To auto-deploy an archived application, copy its archive file to the /autodeploy directory. WebLogic Server automatically sets the application’s deployment mode to stage mode.
A deployment unit that was auto-deployed can be dynamically redeployed while the server is running. To dynamically redeploy, copy the new version of the archive file over the existing file in the /auto-deploy directory.
To undeploy an archived deployment unit that was auto-deployed, delete the application from the /autodeploy directory. WebLogic Server stops the application and removes it from the configuration.
If auto-deployment is enabled, when an application is copied into the \auto-deploy directory of the Administration Server, the Administration Server detects the presence of the new application and deploys it automatically (if the Administration Server is running). If WebLogic Server is not running when you copy the application to the \auto-deploy directory, the application is deployed the next time the WebLogic Server Administration Server is started. Auto-deployment deploys only to the Administration Server.
You can run a WebLogic Server domain in two different modes: development and production. Only development mode allows you use the auto-deployment feature
Development mode enables a WebLogic Server instance to automatically deploy and update applications that are in the domain_name/auto-deploy directory (where domain_name is the name of a WebLogic Server domain).
Production mode disables the auto-deployment feature and prevents any applications you place in the auto-deploy directory after you switch to production mode from being deployed. When you switch from development mode to production mode, any applications that were previously deployed via the auto-deploy directory remain deployed; if you wish to undeploy or redeploy such applications after you have switched to production mode, you must undeploy or redeploy them manually (for instance, with the WebLogic. Deployer command and the -undeploy or -redeploy options, as described in WebLogic. Deployer Command-Line Reference).
To auto-deploy an archived application, copy its archive file to the /autodeploy directory. WebLogic Server automatically sets the application’s deployment mode to stage mode.
A deployment unit that was auto-deployed can be dynamically redeployed while the server is running. To dynamically redeploy, copy the new version of the archive file over the existing file in the /auto-deploy directory.
To undeploy an archived deployment unit that was auto-deployed, delete the application from the /autodeploy directory. WebLogic Server stops the application and removes it from the configuration.
Copy the application browsestore.war the auto deployment folder in the development Environment .
The application will be automatically deployed.
You can check the application by hitting http://localhost:7001/browsestore/
If you remove the application from the auto Deployment folder the application will automatically removed from Deployment.
WebLogic Scripting Tool(WLST):
Wlst is a kind of scripting tool which is a combination of jython and python language.
The WebLogic Scripting Tool (WLST) is a command-line scripting environment that you can use to create, manage, and monitor WebLogic Server domains. It is based on the Java scripting interpreter, Jython. In addition to supporting standard Jython features such as local variables, conditional variables, and flow control statements, WLST provides a set of scripting functions (commands) that are specific to WebLogic Server.
You can use WLST as the command-line equivalent to the WebLogic Server. Administration Console (WLST online) or as the command-line equivalent to the Configuration Wizard (WLST offline).
Three types of modes : 1) Interactive mode. 2) Scripting 3) Embedded.
Interactive mode, in which you enter a command and view the response at a command-line prompt, is useful for learning the tool, prototyping command syntax, and verifying configuration options before building a script. Using WLST interactively is particularly useful for getting immediate feedback after making a critical configuration change. The WLST scripting shell maintains a persistent connection with an instance of WebLogic Server.
Script Mode: Scripts invoke a sequence of WLST commands without requiring your input, much like a shell script. Scripts contain WLST commands in a text file with a .py file extension, for example, filename.py. You use script files with the Jython commands for running script.
Embedded mode, you instantiate the WLST interpreter in your Java code and use it to run WLST commands and scripts. All WLST commands and variables that you use in interactive and script mode can be run in embedded mode. We don’t use this mode generally.
To invoke the wlst go to C:\Oracle\Middleware\wlserver_10.3\common\bin\wlst.cmd and execute wlst.cmd
You can use WLST as the command-line equivalent to the WebLogic Server Administration Console (WLST online) or as the command-line equivalent to the Configuration Wizard (WLST offline).
Offline: Without connecting to a running WebLogic Server instance, you can use WLST to create domain templates, create a new domain based on existing templates, or extend an existing, inactive domain. You cannot use WLST offline to view performance data about resources in a domain or modify security data (such as adding or removing users).
Online: You can use WLST to connect to a running Administration Server and manage the configuration of an active domain, view performance data about resources in the domain, or manage security data (such as adding or removing users). You can also use WLST to connect to Managed Servers, but you cannot modify configuration data from Managed Servers.
The WebLogic Scripting Tool (WLST) is a command-line scripting environment that you can use to create, manage, and monitor WebLogic Server domains. It is based on the Java scripting interpreter, Jython. In addition to supporting standard Jython features such as local variables, conditional variables, and flow control statements, WLST provides a set of scripting functions (commands) that are specific to WebLogic Server.
You can use WLST as the command-line equivalent to the WebLogic Server. Administration Console (WLST online) or as the command-line equivalent to the Configuration Wizard (WLST offline).
Three types of modes : 1) Interactive mode. 2) Scripting 3) Embedded.
Interactive mode, in which you enter a command and view the response at a command-line prompt, is useful for learning the tool, prototyping command syntax, and verifying configuration options before building a script. Using WLST interactively is particularly useful for getting immediate feedback after making a critical configuration change. The WLST scripting shell maintains a persistent connection with an instance of WebLogic Server.
Script Mode: Scripts invoke a sequence of WLST commands without requiring your input, much like a shell script. Scripts contain WLST commands in a text file with a .py file extension, for example, filename.py. You use script files with the Jython commands for running script.
Embedded mode, you instantiate the WLST interpreter in your Java code and use it to run WLST commands and scripts. All WLST commands and variables that you use in interactive and script mode can be run in embedded mode. We don’t use this mode generally.
To invoke the wlst go to C:\Oracle\Middleware\wlserver_10.3\common\bin\wlst.cmd and execute wlst.cmd
You can use WLST as the command-line equivalent to the WebLogic Server Administration Console (WLST online) or as the command-line equivalent to the Configuration Wizard (WLST offline).
Offline: Without connecting to a running WebLogic Server instance, you can use WLST to create domain templates, create a new domain based on existing templates, or extend an existing, inactive domain. You cannot use WLST offline to view performance data about resources in a domain or modify security data (such as adding or removing users).
Online: You can use WLST to connect to a running Administration Server and manage the configuration of an active domain, view performance data about resources in the domain, or manage security data (such as adding or removing users). You can also use WLST to connect to Managed Servers, but you cannot modify configuration data from Managed Servers.
Step 1: Set class path first (C:\Oracle\Middleware\user_projects\domains\base_domain\bin\SetDomainEnv.cmd)
Step 2: enter WLST.cmd (C:\Oracle\Middleware\wlserver_10.3\common\bin\wlst.cmd)
Installing WLST and goto offline mode.
Step 3: connect(‘username’,’password’,’url’) enter
Ex: connect(‘webLogic’,’webLogic1’,’t3://localhost:7001’) or just connect()
To connect to the domain specified port number. And go to online mode.
wls:/base_domain/serverConfig>
Step 4: edit()
Step 5: startEdit()
You go to edit mode and deploy an application after this.
Step 6: deploy an applicationSyntax: deploy(‘appname’,’app path’,targets=’servers’)
Step 7: activate()
Step 8: disconnect() disconnect and come to offline state.
Step 9: exit() come out to the WLST.
Step 2: enter WLST.cmd (C:\Oracle\Middleware\wlserver_10.3\common\bin\wlst.cmd)
Installing WLST and goto offline mode.
Step 3: connect(‘username’,’password’,’url’) enter
Ex: connect(‘webLogic’,’webLogic1’,’t3://localhost:7001’) or just connect()
To connect to the domain specified port number. And go to online mode.
wls:/base_domain/serverConfig>
Step 4: edit()
Step 5: startEdit()
You go to edit mode and deploy an application after this.
Step 6: deploy an applicationSyntax: deploy(‘appname’,’app path’,targets=’servers’)
Step 7: activate()
Step 8: disconnect() disconnect and come to offline state.
Step 9: exit() come out to the WLST.
Start the WLST.cmd from the location C:\Oracle\Middleware
\wlserver_10.3\
common\bin\wlst.cmd and type connect() give the username and the password and the admin server URL .
Then we have to start the Edit session
type Edit() and then StartEdit()
Syntax: deploy(‘appname’,’app path’,targets=’servers’)
Activate() the changes and the application will get deployed on the Admin Server.
Activate() the changes and the application will get deployed on the Admin Server.
You will be able to see your application
Deployed in your Console.
You can access the application by hitting the URL:http://localhost:7001/Calendar/
Deploying and un deploying the application through script
Download the deploy.py file and paste it in the locationD:\Oracle\Middleware\
wlserver_10.3\common\bin
1st We have to run the SetDomainEnv.cmd from the domain where we are gonig to deploy our Application .
2nd Run the following command
java weblogic.WLST deploy.py
Note :Please Edit the deploy.py file according to your application and Environment
Download the undeploy.py file and paste it in the locationD:\Oracle\Middleware\
wlserver_10.3\common\bin
1st We have to run the SetDomainEnv.cmd from the domain where we are gonig to deploy our Application .
2nd Run the following command
java weblogic.WLST undeploy.py
Note :Please Edit the undeploy.py file according to your application and Environment
WebLogic server provides three different modes for staging archive files.
1) Stage mode 2) No-stage mode 3) External stage mode
1) Stage mode: The administrator server copies the deployment unit files to the staging directories of target servers and they are deployed using local copy.
1.This mode is useful when deploying small or moderate size applications and prevents having a single point of failure if the original copy is not accessible.
2. This is the default staging mode for managed server.
2) No-stage mode: The deployment units are deployed using the same physical copy, which must be accessible by the Administrator server and target servers.
1. The administrator server does not copy the deployment unit files to the target server.
2. This mode is useful when deploying very large deployments to multiple targets and for deployment that require dynamic updates.
3. This is the default staging mode for the Administrator server.
3) External stage mode: In the External stage mode you must copy the deployment units manually to the correct staging directories before deployments.
1.Use this staging mode for deployments where you want to manually control the distribution of deployment files to target servers.
2.This mode prevents deployment information beginning dynamically updated . In this case the administration server access the original deployment unit for validation.
1) Stage mode 2) No-stage mode 3) External stage mode
1) Stage mode: The administrator server copies the deployment unit files to the staging directories of target servers and they are deployed using local copy.
1.This mode is useful when deploying small or moderate size applications and prevents having a single point of failure if the original copy is not accessible.
2. This is the default staging mode for managed server.
2) No-stage mode: The deployment units are deployed using the same physical copy, which must be accessible by the Administrator server and target servers.
1. The administrator server does not copy the deployment unit files to the target server.
2. This mode is useful when deploying very large deployments to multiple targets and for deployment that require dynamic updates.
3. This is the default staging mode for the Administrator server.
3) External stage mode: In the External stage mode you must copy the deployment units manually to the correct staging directories before deployments.
1.Use this staging mode for deployments where you want to manually control the distribution of deployment files to target servers.
2.This mode prevents deployment information beginning dynamically updated . In this case the administration server access the original deployment unit for validation.
No comments:
Post a Comment