Deploying Web Applications


Now that we ve reviewed the structure of a Web application, the contents of its descriptor files, and the techniques available for creating an exploded Web application and archive file, it is time to examine the options for deploying Web applications to WebLogic Server. This part of the chapter concentrates on the techniques from the developer s point of view ”how to deploy the application in a single server or workstation environment for the purposes of development and unit testing. Chapter 11 describes techniques and best practices in a multiserver, managed, clustered environment.

There are three basic ways to deploy a Web application, or any other J2EE application, in a WebLogic Server environment:

  • Automatic deployment

  • WebLogic deployer utility or Ant task

  • WebLogic Console deployment

This list represents our order of preference for deploying applications in a single server or workstation environment. We ll examine each option in the following sections, followed by a brief discussion of the steps required to configure security information for proper admin site operation.

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 applications directory for new applications as well as modifications to existing applications. When a new application is placed in the applications 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 auto-deployment, among other things. Note that this variable was STARTMODE in previous versions of WebLogic Server.

Next, copy the Web application archive file or exploded Web application directory structure to the applications 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 applications directory. As indicated in Figure 5.6, an archive file should be located directly in the applications root directory, not in a subdirectory, and an exploded application should include a top-level directory.

click to expand
Figure 5.6:  Web applications deployed in applications 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. Users will access pages in the applications using http://localhost:port/webapp1/... and http://localhost:port/webapp2/... URL locations.

When the new file or directory structure appears in the applications 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. Mission accomplished!

Warning  

Depending on the size of your Web application, it is possible that the server will begin deploying the application before the copying process is complete. The server is smart enough to sense this race condition and wait in the case of an archive file, but there is no way for it to know when the copying process is complete for an exploded application. It is safer to copy a new, exploded application directory structure to the applications directory while the administration server is shut down. When the server is started, the new application will be sensed and automatically deployed.

The bigrez.com application uses this automatic deployment technique. The dist task in the build.xml file places the exploded application files in the applications directory in preparation for automatic deployment. No additional steps or tasks are required to deploy the application or modify the contents of the deployed application, although for reasons we ll describe in a moment, you need to signal the server when a modification is made to the exploded application to force a redeployment.

Applications deployed using archive files can be redeployed automatically by simply overwriting the existing version of the archive file in the applications 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 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.

The bigrez.com application uses an enterprise application, so there is a REDEPLOY file located in the META-INF directory used for this purpose. A redeploy task in the build.xml file touches the REDEPLOY file to cause a redeployment of the exploded application:

 <target name=redeploy>   <touch file=${deploy.dir}/META-INF/REDEPLOY/> </target> 

Recognize that the new versions of the application files in the exploded directory structure must already be present before requesting the redeployment, or a race condition could occur.

Given the added complexity described here, why would you choose to deploy to a workstation or single-server environment using an exploded Web application? Simply put, the ability to modify JSP pages without redeploying the Web application, or the enclosing enterprise application, provides a big benefit in an iterative development process. In previous versions of WebLogic Server, redeploying the application for a simple page change caused all HttpSession objects and user login contexts to be dropped. This was a strong reason to avoid redeployment for a simple page change. Although WebLogic Server 8.1 has improved the redeployment process for Web applications by retaining session and user authentication information during the process, there can still be a significant overhead associated with redeployment. For example, if the Web application is part of an enterprise application, all of the EJB components in the application must also be undeployed and redeployed. This is clearly a lot of effort to make a simple JSP change.

With an exploded deployment, you simply edit the JSP pages in the working area and invoke a copying function, like the dist task in bigrez.com s build script, to copy the modified pages to the exploded Web application. As you continue browsing the site, new pages will be recompiled by the server when they are accessed by the browser because the timestamp on the JSP file no longer matches the timestamp in the generated class file. WebLogic Server keeps track of files included using the < %@ include file= ... % > directive as well, so changes to .jspf files will also cause the correct JSP pages to be recompiled as they are accessed. Remember that this timestamp checking is controlled by the pageCheckSeconds parameter set in weblogic.xml . The default value is one second, so the behavior described here will apply unless you disable it using that parameter.

This all adds up to a clear advantage to using an exploded application structure during development.

Best Practice  

Use exploded application structures for deployment on developer workstations to allow fine-grained updates to JSP pages without requiring a complete redeployment of the enclosing application. Automatic deployment is sufficient for these installations if you have a good technique for touching the REDEPLOY file to cause redeployments on demand.

WebLogic Deployer Utility and Ant Task

The default WebLogic Server installation includes a utility, weblogic.Deployer , providing a command-line 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 stand-alone server instance in a simple development environment. Chapter 11 discusses deployment of applications in production environments.

The following steps are required to deploy a Web application manually using the weblogic.Deployer utility:

  1. Start the WebLogic Server instance in production mode by including PRODUCTION_MODE=true in the startWebLogic script.

  2. Copy the exploded enterprise application or Web application directory structure to the applications directory or any other desired directory. The weblogic.Deployer utility includes an upload feature that can perform this step if desired, although there is little reason to use it for a stand-alone server on a developer workstation.

  3. Deploy the application using the activate action in the weblogic.Deployer utility.

The first two steps are self-explanatory. Using production mode disables the automatic deployment of archives and directory structures placed in the applications directory, allowing you to control this deployment manually. The application may be placed in the applications directory, as in the automatic deployment case, or it may be placed in any desired directory on the server. 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 http://localhost:7001 -name webapp1    -source /myapps/webapp1.war -targets myserver -activate 

Note that the directory specified in the source option is relative to the domain root directory for the server unless you re using the upload feature, in which case it is relative to the current directory.

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 http://localhost:7001 -name webapp2  -source /myapps/webapp2  -targets myserver -activate 

Redeploying a modified application is accomplished using basically the same command and options with the exception of the targets option. The targets option should be removed for a redeployment request because the option works like a toggle: If an application is already deployed to the targeted server, it will be undeployed. The source option again refers to the archive file or root directory of the exploded application.

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 system -password weblogic ... 

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. Once the application is deployed, however, many of the same redeployment and modification rules apply. For example, changes to JSP pages in exploded Web applications will still cause automatic recompilation of the page when a user accesses it.

The behavior of the server in response to a timestamp change in the REDEPLOY file or archive file itself depends on the setting of PRODUCTION_MODE in the startWebLogic script and the choice of directory containing the application, as shown in Table 5.3. In some cases, the server will automatically redeploy the application, and in other cases you must manually redeploy the application using the weblogic.Deployer utility.

Table 5.3:  Redeployment Behavior Depends on Production Mode and Application Location

Production Mode

Application Directory

Redeployment Behavior

TRUE

applications directory or alternate location

Timestamps are ignored. Modified application must be manually redeployed.

FALSE

applications directory

The server monitors the timestamp of the archive file or REDEPLOY file and automatically redeploys applications.

FALSE

alternate location

Timestamps are ignored. Modified application must be manually redeployed.

Because the automatic deployment feature affects only applications placed in the applications directory, you may combine automatic and manual deployment in the same domain. Leave PRODUCTION_MODE set to false in the start script, place applications using automatic deployment in the applications directory, and place applications using manual deployment in an alternate directory such as myapps .

WebLogic Server 8.1 introduces a new 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=deploy>   <wldeploy user=system password=weblogic              action=deploy source=${domain.dir}/myapps/webapp2 /> </target> 
Best Practice  

Favor the new wldeploy Ant task over the command-line weblogic.Deployer utility when manually deploying or redeploying applications. It provides the same functionality and is much easier to integrate in the overall build and deployment process.

See the BEA online documentation at http://edocs.bea.com/wls/docs81/deployment/tools.html for more information on both the weblogic.Deployer utility and the new wldeploy Ant task.

WebLogic Console Deployment

You can use the WebLogic Console to deploy and manage Web applications in a combined administration/managed server instance or across complex clusters of managed servers. In this chapter, we re interested in the simple case of a combined or stand-alone server instance suitable for development and unit testing on a workstation. Deploying a Web application to a stand-alone server instance involves the following steps:

  1. Start the WebLogic Server instance in production mode by setting PRODUCTION_MODE=true in the startWebLogic script.

  2. Copy the exploded archive file or Web application directory structure to the applications directory or any other desired directory.

  3. Deploy the application using the WebLogic Console.

Using production mode disables the automatic deployment of archives and directory structures placed in the applications directory, allowing you to control this deployment manually through the console. The application may be placed in the applications directory or any desired directory on the server. We suggest a directory such as myapps in the domain directory structure to avoid confusion.

Once the server is running and the applications to be deployed are in place, open the WebLogic Console and click the Deployments->Web Application Modules folder in the left-hand navigation bar. Click the Deploy a new Web Application Module link. The right pane will refresh and display some text describing the deployment process along with an HTML-based directory listing starting at the domain root directory. You should see the standard applications directory, the myapps directory containing your Web applications, and any other directories present at the domain root level. Click the myapps directory link to drill down to that directory and examine its contents. Your application archive files or exploded directory structures should be listed, as shown in Figure 5.7.

click to expand
Figure 5.7:  Contents of the MyApps directory.

Select one of the displayed Web applications using the radio buttons . The console now displays a form allowing you to choose the servers and clusters on which this application should be deployed, if applicable .

Target your application to the current server, myserver , and click the Deploy button to complete the deployment of the new Web application. The display will refresh to present the normal deployment status window for an application containing status information and controls used to manage the application. The new application has now been deployed to the server and is ready for use.

Once the application is deployed using the WebLogic Console, redeployment and modification behavior follow the same rules outlined in the previous section; see Table 5.3 for the behavior under different combinations of deployment mode and application location. Note that the WebLogic Console can also be used to redeploy an exploded, automatic deployment application in lieu of modifying the timestamp on the REDEPLOY file or using one of the utilities described in the previous section.

Best Practice  

Manual application deployment using the administration console requires a number of steps to perform and is not required for developer workstation deployments. Use automatic deployment or one of the deployment utilities outlined in the previous section in these environments.

Creating Required Users and Group for BigRez.com

The bigrez.com application includes two separate Web applications, user and admin . As we discussed in Chapter 4, the admin Web application uses standard J2EE security features to control access to the property maintenance pages. The required users and groups must be created in the default security realm in WebLogic Server to complete the deployment of the bigrez.com Web applications.

After starting the domain, open the WebLogic Console and navigate to the Security folder in the navigation pane on the left. Open the default realm, normally called myrealm , and click on the Groups folder. You should see a list on the right side containing the default groups in the security realm, as shown in Figure 5.8.

click to expand
Figure 5.8:  Groups in the default security realm.

Click on Configure a New Group , and fill out the form, as shown in Figure 5.9, to create the new HotelAdministrators group required by the admin Web application. Click on Apply to create the group. Repeat this process to create the new BigRezAdministrators group as well.

click to expand
Figure 5.9:  Create the HotelAdministrators group for the admin site.

Next, click on the Users folder on the left side of the screen. The list on the right should show only the system user and any other users you may have created for testing purposes. Click on Configure a New User and create users with names BIGREZMPLS , BIGREZDUL , and DEWDROP1 using any convenient passwords. These three usernames correspond to the loginId values for the three properties defined in the bigrez.com application and are used to log in as hotel administrators for these hotels. Make these users members of the HotelAdministrators group by adding them to the group one at a time through the Groups tab in each user display. Repeat this process to create a BIGREZADMIN user and assign it to the BigRezAdministrators group.

The required users and groups are now available in the security realm. Hotel managers may log in to the admin site using these hotel-specific usernames and passwords to access and maintain property information for the corresponding hotels. System administrators log in to the admin site using the BIGREZADMIN username and password and have access to all properties.




Mastering BEA WebLogic Server. Best Practices for Building and Deploying J2EE Applications
Mastering BEA WebLogic Server: Best Practices for Building and Deploying J2EE Applications
ISBN: 047128128X
EAN: 2147483647
Year: 2003
Pages: 125

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net