Benefits of a Multiple Deployment Plan Workflow Multiple Deployment Plan Ownership and Limitations

4-8 Deploying Applications to Oracle WebLogic Server Figure 4–3 Multiple Deployment Plan Workflow 4. For subsequent releases of the application, each deployer uses their customized deployment plan to configure the application for deployment. Using the customized plan allows deployers to perform deployments with the weblogic.Deployer or automate deployments using WLST.

4.2.2.1 Benefits of a Multiple Deployment Plan Workflow

Using the multiple deployment plan workflow provides the following benefits: ■ It enables the administrator or deployer to manage both the application configuration and environment configuration in tandem. ■ It enables deployers to automate the deployment process by using a custom plan that fully configures the application for their application. In general, you would use a multiple deployment plan workflow if your organization has many deployment environments that change frequently, making it difficult or impossible to maintain a single master deployment plan.

4.2.2.2 Multiple Deployment Plan Ownership and Limitations

The multiple deployment plan workflow assumes that the deployer or administrator rather than the programming or design team owns and maintains the deployment configuration for an application. It also assumes that the basic J2EE configuration of the application rarely changes, because certain J2EE configuration changes would render a deployers custom configuration plans invalid. For example, if a module in an Enterprise application is added, removed, or changed, custom deployment plans referencing the module would become invalid. In this case, each deployer would need to re-create a custom plan by configuring the application using the Administration Console. Configuring Applications for Production Deployment 4-9

4.3 Creating a New Deployment Plan to Configure an Application

The Administration Console automatically generates or updates a valid XML deployment plan for an application when you interactively change deployment properties for an application that you have installed to the domain. You can use the generated deployment plan to configure the application in subsequent deployments, or you can generate new versions of the deployment plan by repeatedly editing and saving deployment properties. Generating a deployment plan using the Administration Console involves these steps: 1. Section 4.3.1, Preparing the Deployment Files 2. Section 4.3.2, Installing the Application Archive 3. Section 4.3.2.1, Saving Configuration Changes to a Deployment Plan The sections that follow use the WebLogic Server sample application jspExpressionEar.ear to describe each step.

4.3.1 Preparing the Deployment Files

Use the following the directions to prepare your application for deployment.

1. Create a new root directory and app and plan subdirectories for your application.

For example: mkdir c:\sample_root mkdir c:\sample_root\app mkdir c:\sample_root\plan

2. Download the WebLogic Server sample application jspExpressionEar.ear. Be

sure to save the application to the c:\sample_root\app directory you created in Step 1.

4.3.2 Installing the Application Archive

The Administration Console uses an application installation assistant to help you install a new application for configuration and deployment to a new WebLogic Server environment. After you install an application or module and select deployment targets, the deployment files are available in the WebLogic Server domain and can be configured, distributed, and deployed as necessary. Follow these steps to install the sample application to the examples server domain: Notes: ■ weblogic.PlanGenerator also enables you to generate a basic WebLogic Server deployment plan for applications that have only J2EE deployment descriptors. See Appendix B, weblogic.PlanGenerator Command-Line Reference. ■ You cannot use a deployment plan to change the context-root in an application.xml file. However, if an application is deployed as a library, you can either change the context-root through an weblogic-application.xml file or use the deployment plan to change the context-root in an weblogic-application.xml file.