Deploying web application in Weblogic

There are three basic ways to deploy a web application, or any other Java EE application, in a WebLogic Server environment – Automatic deployment – WebLogic deployer utility or Ant task – WebLogic Console deployment

Automatic Deployment

Automatic deployment is the simplest technique available for deploying an application to an administration server or a combined administration/managed server. If automatic deployment is enabled during the startup process, the administration server will constantly scan the autodeploy directory for new applications as well as modifications to existing applications. When a new application is placed in the autodeploy directory, the administration server immediately attempts to load and deploy the application. When an existing, deployed application is modified, the server immediately attempts to undeploy the old version and deploy the new version of the application. This is exactly the sort of behavior a developer prefers during development and unit testing. Changes can be made to the application and redeployed rapidly to a running server without requiring a complete restart of the server, a big advantage in an iterative development and testing process. Two steps are required to deploy an application using automatic deployment. First, automatic deployment must be enabled for the administration server. In the startWebLogic command or shell script used to start the server, make sure that the PRODUCTION_MODE variable is either set to false or not set, which is the default. This variable is used by the script to control the value of the weblogic.ProductionModeEnabled property in the java command line used to start the server. A value of true means production mode, and false means development mode, which will enable autodeployment, among other things. Next, copy the web application archive file or exploded web application directory structure to the autodeploy directory in the domain. Although applications can be located almost anywhere in the directory structure in general, automatic deployment works only for applications placed in the autodeploy directory. As indicated in below Figure,an archive file should be located directly in the autodeploy root directory, not in a subdirectory, and an exploded application should include a top-level directory. The archive root name, webapp1, and top-level directory name, webapp2, will be used by the server as the initial name and root context for the deployed applications. You can specify a different root context using the element in the weblogic.xml descriptor file in the web application. When the new file or directory structure appears in the autodeploy directory the administration server will immediately sense the new application and attempt to deploy it. Assuming the archive or directory is well structured and contains the required descriptor files, the new application will be deployed and ready for use. Applications deployed using archive files can be redeployed automatically by simply overwriting the existing version of the archive file in the autodeploy directory. This rule holds for all archive types, including web application .war files, EJB .jar files, and enterprise application .ear files. The server senses the timestamp change for the file and automatically undeploys the old application and deploys the new version of the application. Applications deployed using exploded formats present a problem for the server: Which file timestamp should be monitored to sense a change in the application and force a full redeployment? There could be hundreds or thousands of files in the exploded directory structure, making it impossible to monitor all of them for changes. WebLogic Server chose to introduce a special file, REDEPLOY, for this very purpose. The contents of this file do not matter; only the timestamp matters. If you touch the file or otherwise modify its timestamp, the server redeploys the application. The REDEPLOY file is located in the META-INF directory in enterprise applications and in the WEB-INF directory in web applications.

WebLogic Deployer Utility and Ant Task

The default WebLogic Server installation includes a utility, weblogic.Deployer, providing a commandline technique for deploying and managing applications. The weblogic.Deployer utility mirrors the deployment functions available through the WebLogic Console, including the deployment of new applications, redeployment of modified applications, undeploying existing applications, and modifying the targeted servers for an application. The weblogic.Deployer utility also provides an upload capability to move applications from a staging directory to the proper directory in the administration server in preparation for deployment. The weblogic.Deployer utility is invoked using the following basic syntax: java weblogic.Deployer [options] [action] [files] As before, we’ll concentrate here on the actions and options necessary to deploy and redeploy an application to a standalone server instance in a simple development environment. The following steps are required to deploy a web application manually using the weblogic.Deployer utility:

1. Start the WebLogic Server instance using the startWebLogic script or other mechanism.

2. Build the web application as either an exploded directory structure or archive (.war) file using the normal Ant build process. Normally this build script will place the application in some build or output directory within your source code directory structure.

3. If desired, copy the application files or archive file from this build directory to a staging directory on your machine. Copying the application before deploying it will insulate the running version of the application from any builds you make in your source area until you are ready to deploy them.

4. Deploy the application using the deploy action in the weblogic.Deployer utility. The first two steps are self-explanatory. The Deployer utility only works if there is a running WebLogic Server administration server with which to communicate, and the build itself must be complete before deployment can occur. As the optional third step notes, it is often useful to separate the running version of the application from the version in the build directory of your source code structure by performing a distinct copy step to create another copy of the application in a staging directory. This step is not required for deployment, because the Deployer utility can easily deploy the application directly from the build directory or other directory within the source area, but it may prove helpful to you. If you decide to copy the application to a staging directory, we suggest a directory such as myapps in the domain directory structure to avoid confusion. The webapp1 application may now be deployed from the web archive file webapp1.war using the command:

java weblogic.Deployer -adminurl t3://localhost:7001 -name webapp1 -source /domains/mydomain/myapps/webapp1.war -targets myserver -deploy

You can deploy exploded applications such as webapp2 in this manner by referring to the root directory of the exploded web application in the source option:

java weblogic.Deployer -adminurl t3://localhost:7001 -name webapp2 -source /domains/mydomain/myapps/webapp2 -targets myserver -deploy

 

Redeploying a modified application is accomplished using the redeploy action and specifying the name of the application, as shown here:

java weblogic.Deployer -adminurl t3://localhost:7001 -name webapp2 -redeploy

The example command lines shown so far require you to enter the administrator’s username and password to complete the operation. You can specify these values on the command line with the user and password options: java weblogic.Deployer -user weblogic -password weblogic1 … Other useful options include debug and verbose, providing details during the deployment operations to assist in troubleshooting problems. Using the weblogic.Deployer utility to deploy web applications replaces the automatic deployment performed by WebLogic Server when running in development mode and changes how the server reacts to updated versions of the application files. In general, you must use the redeploy action before a running copy of the application will reflect application updates. WebLogic Server will not automatically redeploy the application based on a timestamp change in the REDEPLOY file or archive file itself as it does when deployment is accomplished using the autodeploy directory. Changes to JSP pages in exploded web applications will still cause automatic recompilation of the page when a user accesses it.   WebLogic Server includes an Ant task, wldeploy, providing the same basic functions as the weblogic.Deployer utility. Deploying the exploded webapp2 web application from the /myapps directory requires an Ant target similar to the following:

<target name="deploy2">

<wldeploy verbose="true" user="weblogic" password="weblogic1" adminurl="t3://localhost:7001" action="deploy" source="${domain.dir}/myapps/webapp2" />

</target>

WebLogic Console Deployment

Deploying a web application to a standalone server instance involves the following steps:

1. Start the WebLogic Server instance in either production mode or development mode.

2. Optionally, copy the exploded archive file or web application directory structure to a suitable staging directory such as <domainroot>/myapps.

3. Deploy the application using the WebLogic Console. Once the server is running and the applications to be deployed are in place, open the WebLogic Console and click the Deployments link in the left-hand navigation pane. Click the Install button and navigate to the location of your exploded or archived application. Select one of the displayed web applications using the radio buttons. The WebLogic Console displays a set of forms allowing you to choose the type of deployment, the name to use for the deployment, and the security and staging models, and gives you the option to perform additional configuration steps before deployment. The application will automatically be targeted to the combined administration and managed server, if applicable, requiring little or no manual configuration. Once you click Finish on the final form in the process, your application will be loaded and deployed to the server, and you’ll end up on the Overview tab for the deployment. The new application has now been deployed to the server and is ready for use. Note that in production mode you’ll need to start the application before using it. Once the application is deployed using the WebLogic Console, redeployment and modification behavior follow the same rules outlined in the previous section. Modified JSP pages in an exploded application may be recompiled by the server as the pages are encountered, depending on the value of <page-check-seconds>, but all other application changes will require a redeployment using either the WebLogic Console or a utility such as weblogic.Deployer or wldeploy. Redeploying an application using the WebLogic Console does not require that you delete and reinstall the application. Simply open the list of deployed applications by clicking the Deployments link in the left-hand navigation pane, check the box next to the application, and click the Update button below the list. This has the same effect as the redeploy action in the Deployer utility.

In case of any ©Copyright or missing credits issue please check CopyRights page for faster resolutions.