Valid domain directories are indicated by the Domain directory folder icon, shown here. To select a domain template as the source for the new template.
From the list of templates displayed in the Templates pane, select a template. The templates in the list are located in the directory specified in the Locate Additional Templates pane. If you want to change the directory, click Browse , and then either navigate to the appropriate directory or enter the path manually. Use the Describe the Template screen to provide a description for the template. If you selected a WebLogic domain as the source for the new template, enter the information required for the domain, and click Next.
If you selected a template as the source for the new template, information about the selected template is displayed. Review the information, and, if necessary, change it to suit the requirements of your domain. When done, click Next. Table describes the fields on the Describe the Template screen. Fields marked with an asterisk are required. Table Describe the Template. Enter a valid name for the domain template. The name must be a string of characters, and can include spaces. Enter the name of the author of the template.
The author must be a string of characters, and can include spaces. Enter the name of the category in which you want this template to be displayed. The category must be a string of characters, and can include spaces. Enter a description of the domain template. The description must be a string of characters, and can include spaces. Table describes the fields on this screen. This field defaults to a name based on the values you entered in the Name and Version fields on the previous screen.
If the template name includes spaces, they are replaced by a period. For example, if you entered "My new domain" for Name and 1. If you want to store the file elsewhere, either enter the full path to the desired directory or click the Browse button to select the directory. The Add or Omit Applications screen is displayed only if applications are included in the template or domain that you selected.
By default, the Domain Template Builder includes applications from the domain or template you specified as the source for the template that you are creating.
For example:. If you selected a template as the source for the new template, and if the source template has a separately defined applications directory, all the application files defined in the applications directory are included by default. If you selected a domain as the source for the new template, applications that fulfill the following conditions are included by default:.
Applications that are defined in the config. Applications that are not considered internal applications in your product installation are included by default. In the Applications pane, review the list of applications to be included in your template. By default, all the applications are selected. The listed applications reside in the directory specified in the Current Application Path field. The applications are copied into your template from this location.
To change the relative path of the directory into which an application is imported, do the following:. In the Imported Application Path field, enter the relative path you want to use after the application is imported into your template.
By default, the Domain Template Builder includes files from the WebLogic domain or template you specified as the source for the new template. If you selected an existing template as the source for the new template, all files from the source template are automatically included.
If the existing template defines a separate applications directory, the applications in the template are listed under the Applications Root Directory in the Current Template View pane. If you selected a domain as the source for your new template, the following files and directories are included by default:.
All files in the root directory with the following extensions:. All files in the security directory that are not created automatically during domain creation. All files and subdirectories in the config directory that are not included by the Domain Template Builder automatically during template creation. For example, config. You may also need to include other files from your domain or file system that are required by the applications. The Add Files screen lets you to review, add, or remove files in the template.
You can use the filters in the Show File Types drop-down list to limit the files displayed in this pane. For example, to display only files with the. If you attempt to add a file that is created automatically by the Configuration Wizard at domain creation time, an error message is displayed.
You can add your own SQL scripts to the new template, so that the scripts are available when you create a WebLogic domain based on the template. You can also specify the order in which the scripts are executed. When you create a WebLogic domain based on this template, the databases and associated SQL scripts that you include are displayed on the Run Database Scripts screen of the Configuration Wizard.
In the Database Type and Version pane, select a database from the Type drop-down list. Select the database version from the Version drop-down list or enter a version number directly in the field. The Selected Database Scripts pane displays a tree-view of all the databases and associated SQL scripts included in the template.
The specified sequence is reflected in the Selected Database Scripts pane. The Configure the Administration Server screen is displayed. In every WebLogic domain, one server must be designated as the Administration Server. The Administration Server is the central point from which the entire domain is managed. You can define the listen-address and listen-port for the Administration Server on the Configure the Administration Server screen of the Domain Template Builder.
The Configure Administrator Username and Password screen is displayed. When you create a domain template, the administrator username and password from the original WebLogic domain or template are included in your new template. If necessary, you can modify this username and password. You can also provide extra security for application resources using the following security features:.
Users and groups: Classification of individuals and groups of individuals who may be granted a security role. Typically, a group is a collection of users who share a role or function within a company, such as working in the same department. Global security roles: Dynamically computed privileges that are used to restrict access to WebLogic resources. These privileges are granted to or withheld from users according to the roles that they are assigned.
Specify a valid username in the Username field. This name is used to start the Administration Server and connect to it. User names are case sensitive. Specify a valid password in the User password field. A valid password must contain at least eight case-sensitive characters and at least one numeric character. The password value is encrypted. If you want to configure additional users, groups, and global roles, select Yes at the bottom of the screen, and click Next.
If you do not want to configure additional users, groups, and global roles, select No , and click Next. You are creating a domain template and you selected the option to configure users, groups, and global roles on the Configure Administrator Username and Password screen.
You are creating an extension template and you selected Yes on the Security Configurations Option screen. A user is an entity that can be authenticated.
The user can be a person or a software entity, such as a Java client. Each user is given a unique identity within a security realm. A group is a collection of users who usually have something in common, such as that they are working in the same department in a company.
A security role is a privilege granted to users or groups based on specific conditions. Like groups, security roles allow you to restrict access to WebLogic resources for multiple users simultaneously. PlanGenerator command, weblogic. PlanGenerator inspects all Java EE deployment descriptors in the selected application, and creates a deployment plan with null variables for all relevant WebLogic Server deployment properties that configure external resources for the application.
Using this template deployment plan, an administrator using the WebLogic Server Administration Console is directed to assign valid resource names and tuning properties for each null variable before the application can be deployed. A developer generally customizes the template plan to add one or more WebLogic Server tuning properties for the application. The template deployment plan generated in Generating a Template Deployment Plan using weblogic.
PlanGenerator contains only those deployment properties that resolve external dependencies for the application. The WebLogic Server Administration Console enables you to easily add deployment plan variables for individual deployment descriptor properties as needed. To modify a deployment configuration using the WebLogic Server Administration Console, you must first install the application and existing deployment plan as described in Steps for Creating an Application Installation Directory.
After installing the exported application, follow the steps in Update a deployment plan in Oracle WebLogic Server Administration Console Online Help to add new tuning properties to the deployment plan. If you modify any deployment properties defined as variables in the application's deployment plan, your changes are written back to a new version of the plan file. If the application that was installed from an installation directory, the WebLogic Server Administration Console stores the generated configuration files in the plan subdirectory by default.
You cannot use the WebLogic Server Administration Console to remove variable definitions from the deployment plan or assign a null value for a deployment property. The variable-definition stanza in a deployment plan defines the names and values of variables used for overriding WebLogic Server deployment descriptor properties.
The module-override element may contain one or more variable-assignment elements that define where a variable is applied to a given deployment descriptor. To remove a variable from a deployment plan, use a text editor to delete:. The variable definition from the variable-definition stanza. All variable-assignment elements that reference the deleted variable.
For example, change:. The WebLogic Server Administration Console automatically validates the deployment configuration for a newly-installed application or module.
Take these steps to validate a custom deployment plan that you have created during the export process. Keep in mind recommended best practices when exporting an application's deployment configuration. The primary goal for exporting an application is to create null variables for all of an application's external resource dependencies.
This ensures that deployers have the ability to assign resource names based on resources available in their target environment. Use weblogic. PlanGenerator only for exporting resource dependencies. Using weblogic. PlanGenerator to export other categories of deployment descriptor properties generally results in too many variables in the deployment plan.
Use the WebLogic Server Administration Console to add individual tuning property values to the deployment plan, or to validate a custom deployment plan.
PlanGenerator allow you to remove variables from a plan or set null values for variables. Use a text editor when necessary to complete these tasks. This process helps administrators easily deploy the application into non-development environments. Overview of the Export Process Exporting an application's deployment configuration is the process of creating a custom deployment plan for deploying the application into new WebLogic Server environments.
Goals for Exporting a Deployment Configuration The primary goals in exporting a deployment configuration are: To expose the external resources requirements of the application as null variables in a deployment plan. Tools for Exporting a Deployment Configuration WebLogic Server provides the following tools to help you export an application's deployment configuration: weblogic. Steps for Exporting an Application's Deployment Configuration Exporting an application's deployment configuration typically involves several steps.
Staging Application Files for Export Oracle recommends placing application files into an application installation directory before exporting the deployment configuration. To create an application installation directory:. PlanGenerator The weblogic. This may be necessary for the following reasons:. The variable-definition stanza in a deployment plan defines the names and values of variables used for overriding WebLogic Server deployment descriptor properties.
The module-override element may contain one or more variable-assignment elements that define where a variable is applied to a given deployment descriptor. To remove a variable from a deployment plan, use a text editor to delete:. For example, change:. The Administration Console automatically validates the deployment configuration for a newly-installed application or module. To validate a custom deployment plan that you have created during the export process:.
This script outputs the product breadcrumb required for edocs documentation. To expose the external resources requirements of the application as null variables in a deployment plan. Any external resources required by the application are subject to change when the application is deployed to a different environment. For example, the JNDI names of datasources used in your development environment may be different from those used in testing or production.
Exposing those JNDI names as variables makes it easy for deployers to use available resources or create required resources when deploying the application. Using empty null variables forces the deployer to fill in a valid resource name before the application can be deployed. To expose additional configurable properties, such as tuning parameters, as variables in a deployment plan. Certain tuning parameters that are acceptable in a development environment may be unacceptable in a production environment.
For example, it may suffice to accept default or minimal values for EJB caching on a development machine, whereas a production cluster would need higher levels of caching to maintain acceptable performance. Exporting selected tunables as deployment plan variables helps an administrator focus on important tuning parameters when deploying the application.
The Administration Console highlights tuning parameters exposed as variables in a deployment plan, but does not require a deployer to modify them before deployment. PlanGenerator creates a template deployment plan with null variables for selected categories of WebLogic Server deployment descriptors. This tool is recommended if you are beginning the export process and you want to create a template deployment plan with null variables for an entire class of deployment descriptors see Understanding Deployment Property Classifications.
You typically need to manually modify the deployment plan created by weblogic. PlanGenerator , either manually or using the Administration Console, to delete extraneous variable definitions or add variables for individual properties. The Administration Console updates or creates new deployment plans as necessary when you change configuration properties for an installed application.
You can use the Administration Console to generate a new deployment plan or to add or override variables in an existing plan. The Administration Console provides greater flexibility than weblogic.
PlanGenerator , because it allows you to interactively add or edit individual deployment descriptor properties in the plan, rather than export entire categories of descriptor properties. Non-configurable properties cannot be changed by an administrator during a deployment configuration session. Non-configurable properties are used to describe application behavior that is fundamental to the basic operation of the application. For example, the ejb-name property is categorized as non-configurable, because changing its value also requires changing the EJB application code.
0コメント