Deploying Applications to WebLogic Server
When you receive a new application, or a new version of an application, from your development or quality assurance teams, the application has generally been configured for a development or testing environment. This means that the application may use specific resource names and performance tuning settings that match the available resources on the target servers used in the development or QA environments where the application was last deployed.
Because development and testing environments can be significantly different from the production environment in which the application is ultimately deployed, an Administrator must configure the application to use resource names and performance tuning parameters that are valid and appropriate for the production environment.
The basic deployment configuration for an application is defined in multiple XML documents, known as deployment descriptors, that are included as part of the application archive file that you receive for deployment. Deployment descriptor files fall into two separate categories:
For the purposes of a production deployment, you should treat both the J2EE and WebLogic Server deployment descriptors as part of the application's source code, which is owned by your development team. Do not edit application deployment descriptors in order to configure an application for deployment to a production environment. Instead, use the Administration Console to persist configuration changes into a WebLogic Server deployment plan, which is described in the next section.
A WebLogic Server deployment plan is an optional XML document that resides outside of an application archive and configures an application for deployment to a specific WebLogic Server environment. A deployment plan works by setting deployment property values that would normally be defined in an application's WebLogic Server deployment descriptors, or by overriding property values that are already defined in a WebLogic Server deployment descriptor.
Deployment plans are created and owned by the Administrator or deployer for a particular environment, and are stored outside of an application archive or exploded archive directory. As a best practice, BEA recommends storing each deployment plan for a single application in its own
plan subdirectory of the application's root directory (See Creating an Application Installation Directory).
Deployment plans help the Administrator easily modify an application's WebLogic Server configuration for deployment into to multiple, differing WebLogic Server environments without modifying the deployment descriptor files included in the application archive. For example, a deployment plan enables you to deploy an application to multiple domains, or to multiple target servers and clusters within the same domain, that have are different configurations. To deploy the application to a new environment, an Administrator simply creates or uses a new deployment plan as necessary.
Figure 4-1 shows how deployment plans are typically used when releasing a new version of an application. During development, a programmer creates both J2EE and WebLogic Server deployment descriptors to configure the application for repeated deployments to their development environment. At this point, the application is generally deployed from an split development directory, rather than an archive file, to facilitate easy editing and redeployment of the application. A deployment plan is not necessary during deployment, because the developer has full access to the application's deployment descriptors, and the development environment is typically a simple, single-server domain. Figure 4-1 shows that the development server uses a simple PointBase database for development, named "DevDataSource," and the
weblogic-ejb-jar.xml descriptor identifies the resource. Application tuning parameters are not defined in the development configuration, because the developer is focused on the basic semantics and behavior of the application.
To release a new version of the application, the developer packages the application into an archive file and delivers it to an Administrator or deployer in the quality assurance team. At this point, the embedded deployment descriptors provide a configuration that is valid for the development environment used by the developer, but are not valid for the testing environment where the application must be deployed. Figure 4-1 shows that the testing environment uses a different datasource name than the one used during development. To deploy the application, the Administrator of the testing environment generates a deployment plan to override the datasource name configured in the application's embedded deployment descriptors. Figure 4-1 shows that the deployment plan configures the application to use the resource named "QADataSource."
Similarly, when the application is released into production, the Administrator of the staging or production environment creates or uses another deployment plan to configure the application. Figure 4-1 shows that the production deployment plan once again overrides the application deployment descriptor to identify a new JDBC datasource name. For this environment, the deployment plan also defines tuning parameters to make better use of the additional resources available in the production domain.
For the Administrator, the primary goal of configuring an application for production deployment is to generate a new deployment plan that is valid and appropriate for the target WebLogic Server environment. Specifically, the deployment plan must resolve all external resources references for the application to refer to valid resources available in the target environment. If the Application's configuration does not define to valid external resources for the target servers, the application cannot be deployed.
A deployment plan can optionally define or override WebLogic Server tuning parameters, to make ideal use of resources in the target environment. Defining tuning parameters is not required in order to successfully deploy an application. If an application's deployment descriptors and deployment plan do not define tuning parameters, WebLogic Server uses default values.
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.
If you did not install WebLogic Server sample applications when you installed WebLogic server, follow the directions in this section to prepare your application for deployment. If you installed WebLogic Server sample applications when you installed WebLogic Server, proceed to the next section Installing the Application Archive.
jspExpressionEar.earfrom http://download.oracle.com/docs/cd/E13222_01/wls/docs90/jspExpressionEar.ear. Be sure to save the application to the
c:\sample_root\appdirectory you created in Step 1.
The Administration Console uses an application installation assistant to help you install a new application for configuration and deployment to a WebLogic Server environment. The installation assistant copies deployment files to the Administration Server and selects target WebLogic Server instances for deploying the application. After installing an application or module, the deployment files are available in the WebLogic Server domain and can be configured, distributed, and deployed as necessary.
Use the Administration Console to edit deployment configuration properties for the application you installed in the previous section (Installing the Application Archive) and save the configuration to a deployment plan. For example, you could change properties such as the following in the
jspExpressionEar.ear sample application:
\plansubdirectory of the root directory. For example,
The deployment plan generated in Creating a New Deployment Plan to Configure an Application contains the entries shown in Sample Deployment Plan.
deployment-planencapsulates all of the deployment plan's contents.
application-namecorresponds to the deployment name for the application or module.
variable-definitiondefines one or more
nameof a variable used in a plan and a
valueto assign (which can be null). The sample plan shown in Sample Deployment Plan contains variable definitions for the changes you made to the Session Invalidation Interval and Session Timeout properties.
module-overrideelements define each module name, type, and deployment descriptor that the deployment plan overrides. A
module-descriptorelement can optionally contain a
variable-assignmentwhich identifies a variable name used to override a property in the descriptor, and the exact location within the descriptor where the property is overridden.
The sample plan shown in Sample Deployment Plan contains module override elements for the Enterprise Application, the embedded Web application, and the enclosing root directory. The module-descriptor entry for the
weblogic.xml descriptor file contains two
variable-assignment elements that override the property values for the Session Invalidation Interval and Session Timeout properties you changed in Saving Configuration Changes to a Deployment Plan.
By default, the values in
variable-assignment elements are added to the values that are already defined in the descriptor. You can change this behavior and cause the
variable-assignment element to replace or remove the values that are defined in the descriptor by setting the
operation subelement in the
variable-assignment element to the value
security-role-assignmentelement in weblogic-ejb-jar.xml, you map
ejbRoleto the principal named
security-role-assignmentelement defined in weblogic-ejb-jar.xml, so that
ejbRoleis mapped to
user1, you could achieve the desired override behavior by setting appropriate values for the
operationelements in the deployment plan. Make sure to set the value of
For more information about the contents of a WebLogic Server deployment plan, see the Deployment Plan Reference and Schema.
Applications that you receive for deployment may come with varying levels of configuration information. If you have an existing deployment plan for an application, simply prepare the application as described in Preparing the Deployment Files and place the deployment plan in the
plan subdirectory of the application root. Then install the application using the instructions in Installing the Application Archive. The Administration Console automatically uses a deployment plan named
plan.xml in the
\plan subdirectory of an application root directory if one is available. If multiple plans are available for your application, they are placed in their own \
plan subdirectories (for example
\plan2), and the Administration Console cannot identify them. Therefore, you must specify, in
config.xml, the plan you want to use. For information on config.xml, see Creating WebLogic Domains Using the Configuration Wizard.
After you install a new application and existing deployment plan, the Administration Console validates the deployment plan configuration against the target servers and clusters that were selected during installation. If the deployment plan contains empty (null) variables, or if any values configured in the deployment plan are not valid for the target server instances, you must override the deployment plan before you can deploy the application. You can also configure tuning parameters to better suit the target environment in which you are deploying the application, as described in Saving Configuration Changes to a Deployment Plan. Changes you make to the application's configuration are saved to a new deployment plan.
If you have a valid deployment plan that fully configures an application for the environment in which you are deploying, you can use either the Administration Console or the
weblogic.Deployer utility to identify the application and plan to use for deployment. Note that any deployment plan you use with the
weblogic.Deployer utility must be complete and valid for your target servers;
weblogic.PlanGenerator does not allow you to set or override individual deployment properties that are defined in the plan. To deploy a new application and existing deployment plan using
weblogic.Deployer, see Deploying an Application with a Deployment Plan.
plansubdirectory of an application root directory.