Oracle recommends that you use pack and unpack to recreate the domain on remote servers. Unlike creating and using a domain template, the configToScript command creates multiple files that must be used together. A domain template is a single JAR file.
In addition, the script that the configToScript command creates:. Requires a WebLogic Server instance to be running. If a server isn't running, the script starts one. Contains only references to applications and other resources. When you run the generated script, the applications and resources must be accessible to the WebLogic domain through the file system.
A domain template is a JAR file that contains all applications and resources needed to create a WebLogic domain. Because the domain template is self-contained, you can use it to create WebLogic domains on separate systems that do not share file systems. For more information on the targeting and deployment of application-scoped modules, see Deploying Applications and Modules with weblogic. If you want to use JDBC resources to connect to a database, modify the environment as the database vendor requires.
If your WebLogic domain contains multiple Managed Servers, and each Managed Server domain directory is located on a remote machine on which the Administration Server does not reside, you can use the WLST writeTemplate command in online mode. When you execute the writeTemplate command while connected to the Administration Server from a remote machine, it dynamically packs the domain on the Administration Server into a template JAR file and transfers the template JAR to the specified directory.
The following sample WLST script demonstrates how to use writeTemplate to create or update a Managed Server domain on a remote machine. Run the script on each remote machine in the domain.
Previous Next JavaScript must be enabled to correctly display this content. Creating and Using a Domain Template Offline A domain template is a JAR file that contains domain configuration documents, applications, security data, startup scripts, and other information needed to create a WebLogic domain. You can create, configure, and manage domains using WLST, command-line utilities, and the Administration Console interchangeably. The method that you choose depends on whether you prefer using a graphical or command-line interface, and whether you can automate your tasks by using a script.
See Script Mode. You can use the scripting tool online connected to a running Administration Server or Managed Server instance and offline not connected to a running server. When WLST is connected to an Administration Server instance, the scripting tool lets you navigate and interrogate MBeans, and supply configuration data to the server. Changing the values of MBeans on Managed Servers can lead to an inconsistent domain configuration.
Using WLST offline, you can create a new domain or update an existing domain without connecting to a running WebLogic Server—supporting the same functionality as the Configuration Wizard. Offline, WLST only provides access to persisted configuration information. You can create new configuration information, and retrieve and change existing configuration information that is persisted in the domain configuration files located in the config directory, for example, config.
WLST is a command-line interpreter that interprets commands either interactively, supplied one-at-a-time from a command prompt, or in batches, supplied in a file script , or embedded in your Java code.
The modes of operation represent methods for issuing WLST commands:. Interactive mode, in which you enter a command and view the response at a command-line prompt, is useful for learning the tool, prototyping command syntax, and verifying configuration options before building a script. Using WLST interactively is particularly useful for getting immediate feedback after making a critical configuration change. Because a persistent connection is maintained throughout the user session, you can capture multiple steps that are performed against the server.
See Recording User Interactions. In addition, each command that you enter for a WebLogic Server instance uses the same connection that has already been established, eliminating the need for user re-authentication and a separate JVM to execute the command.
Scripts invoke a sequence of WLST commands without requiring your input, much like a shell script. Scripts contain WLST commands in a text file with a. You use script files with the Jython commands for running scripts. See Running Scripts. Edit the script to contain the username, password, and URL of the Administration Server and start the server before running this script.
All WLST commands and variables that you use in interactive and script mode can be run in embedded mode. Listing illustrates how to instantiate an instance of the WLST interpreter and use it to connect to a running server, create two servers, and assign them to clusters.
This affects the session handling time and graceful server shutdown time. Set to false if special consideration must be taken to preserve unpatched sessions. This could impact the time it takes for the rollout to complete.
If the patched sessions are not compatible with the unpatched sessions, then forceful shutdown of the servers on the last node may result in loss of session data. If you specify the script parameters using this option, then these parameter values will override the values specified in the JSON file. This operation results in graceful shutdown of the servers, the location of Java Home being updated, the Node Manager being restarted, and the servers being restarted without interrupting the service for the user.
The location of the new Java Home to use. This must refer to a valid Java Home path installed on each machine. A comma-separated list of options, specified as name-value pairs. Valid options include:. If set to true , the operation is evaluated but not executed. Set to true if the sessions between the patched and unpatched versions of Oracle Home are compatible.
The following example shows how to use the rolloutJavaHome command to roll out a new Java Home to the cluster Cluster1. Rolls out a patched Oracle Home to the targeted servers or reverts your targeted servers to use the previous unpatched Oracle Home. This operation results in graceful shutdown of the servers, the Node Manager being restarted, and the servers being restarted without interrupting the service for the user. The location of the archive or local directory containing the version of Oracle Home to roll out, that will replace the existing Oracle Home.
Boolean value. Allows the user to specify that the change being rolled out to a domain is to a previous patch release of Oracle Home. This information is important in determining whether the Administration Server should be updated first or last. Set to True if the Oracle Home being rolled out has an older patch version than the current Oracle Home. The following example shows how to use the rolloutOracleHome command to roll out a new Oracle Home to the domain myDomain.
The process will not automatically revert if it fails. Initiates a rolling restart of all servers in a domain or all servers in a specific cluster or clusters without interrupting the service.
This command provides the ability to sequentially restart servers. This operation involves the graceful shutdown of the servers, and the servers being restarted without interrupting the service for the user.
Name of the domain, cluster, or a comma-separated list of servers on which the rollout takes effect. The following example uses the rollingRestart command to restart all servers in the domain myDomain , one at a time. It then, uses the returned progress object to show the progress and state of the operation. The location of the archive or local directory containing the version of Oracle Home to roll out, and that replaces the existing Oracle Home.
The following example selects the wls. Deselect the selected domain template or application template during the process of domain creation. Version of the domain template to be deselected. The following example deselects the specified domain template during the process of domain creation:.
Deselect the selected custom domain template or application template during the process of domain creation. The following example deselects the wls. Opens an existing domain template for template update. If you are updating the domain template, you must use readTemplateForUpdate instead of readTemplate.
When you open a domain template, you are placed into the configuration bean hierarchy for that domain template, and the prompt is updated to reflect the current location in the configuration hierarchy. WebLogic Server configuration beans exist within hierarchical structures.
In the WLST file system, configuration bean hierarchies correspond to drives; types and instances are directories; attributes and operations are files. WLST traverses the hierarchical structure of configuration beans using commands such as cd, ls, and pwd in a similar way that you would navigate a file system in a UNIX or Windows command shell.
The following example opens the wls. Displays the complete template location path. The default value is false. Adds a new help command group to those shown by the WLST help command. Adds new command help for a command to an existing command group. Once added to the group, the command along with a brief description is displayed in the command list for the group when you enter the help 'commandGroup' command.
Adds a new command help group to those shown by the WLST help command, and specifies the resource bundle in which the help information is defined for the group. Use a unique name for the command group. Do not use a command group name that is already shown by the WLST help command. Represents either a class name or property resource file name. The resource bundle contains help text for entries for the command group using a standard pattern.
The resource bundle name will be passed to ResourceBundle. Multiple command groups can use the same resource bundle. The following example adds the boot command group to the list of groups shown by the help command, and specifies that the help text is located in the property resource file 'myhelp':.
The following example adds the boot command group to the list of groups shown by the help command, and specifies that the help text is located in the class foo. MyResourceBundleClass :. You can also specify whether or not the command is listed by the help 'online' and help 'offline' commands.
Boolean value that determines whether or not the command shows up in the help 'online' output. The default value is 'false'. Boolean value that determines whether or not the command shows up in the help 'offline' output. The following example shows how to add the online command bootDB to the listing output by the help 'boot' and help 'online' commands:. The deploy command returns a WLSTProgress object that you can access to check the status of the command.
If there is an edit session in progress, the deploy command does not block user interaction. Name of the application directory, archive file, or root of the exploded archive directory to be deployed. Comma-separated list of the targets. Each target may be qualified with a Java EE module name for example, module1 server1 enabling you to deploy different modules of the application archive on different servers.
This argument defaults to the server to which WLST is currently connected. Staging mode for the application you are deploying.
If you do not specify a stage mode, the default stage mode is used. On the Administration Server, the default stage mode is nostage and on Managed Servers, it is stage. Name of the deployment plan file. The filename can be absolute or relative to the application directory. Name of the resource group to which this deployment is scoped. Specify a resource group when deploying to a partition resource group or a domain resource group.
The specified resource group must already exist before executing the deploy command. Name of the resource group template to which this deployment is scoped. The specified resource group template must already exist before executing the deploy command. Name of the partition to which this deployment is scoped.
The partition name will be derived from the current invocation context if this argument is not specified. The specified partition must already exist before executing the deploy command. Comma-separated list of deployment options, specified as name-value pairs. This option defaults to true. Default value is true. Make sure the user exists. Specify the deployment order of the application.
The application with the lowest deployment order value is deployed first. This option defaults to false and only applies if gracefulProductionToAdmin is set to true.
Use this option when you are on a different machine from the Administration Server and the deployment files are already at the specified location where the Administration Server is located. This policy is only meaningful for stop and redeploy operations and is mutually exclusive to the retire timeout policy.
This option default to -1 , which specifies graceful timeout. RMI requests arriving within a grace period of prior request scheduled within the grace period will be accepted, and otherwise rejected. This option default to -1, which specifies no grace period. For example, submod mod-jms. A value of 0 indicates that the operation will not time out. This argument defaults to , ms or 5 minutes. Use this option when the Administration Server cannot access the application files through the file system.
The previous example stores the WLSTProgress object returned in a user-defined variable, in this case, progress. You can then use the progress variable to print the status of the deploy command. WLST waits , ms for the process to complete. The following example shows how to set the application version appVersion to a unique identifier to support production side-by-side redeployment. The following example shows how to deploy myapp. Copies the deployment bundle to the specified targets.
The deployment bundle includes module, configuration data, and any additional generated code. The distributeApplication command does not start deployment.
The distributeApplication command returns a WLSTProgress object that you can access to check the status of the command. Comma-separated list of targets. The specified resource group must already exist before executing the distributeApplication command. The specified resource group template must already exist before executing the distributeApplication command.
The specified partition must already exist before executing the distributeApplication command. For a list of valid deployment options, see the options argument description in deploy. The previous example stores the WLSTProgress object in a user-defined variable, in this case, progress. You can then use the progress variable to determine if the distributeApplication command has completed.
The default value is All. Use this option when you are on a remote machine and you cannot copy the code source jar to the Administration Server by other means. Returns the WebLogic DeploymentManager object. You can use the object methods to configure and deploy applications. The following example gets the WebLogicDeploymentManager object and stores it in the wldm variable.
The following example lists all the applications currently deployed in mydomain. Loads an application and deployment plan into memory. When used in online mode, you can connect only to the Administration Server; you cannot connect to a Managed Server. The loadApplication command does not support loading an application from a remote machine. The application must be on the same machine where the Administration Server is running.
Name of the top-level parent application directory, archive file, or root of the exploded archive directory containing the application to be loaded. The target application directory must be on the same machine where the Administration Server is located. Boolean value specifying whether WLST should create a plan in the application directory if the specified plan does not exist.
This argument defaults to true. You can then use myPlan variable to display information about the plan, such as the variables. The redeploy command returns a WLSTProgress object that you can access to check the status of the command. The specified resource group template must already exist before executing the redeploy command. The specified partition must already exist before executing the redeploy command.
Boolean value true or false indicating whether the previous deployment plan override at the resource group level should be removed. For a list of valid deployment options, see options argument description in deploy.
In addition, the following deployment option can be specified for the redeploy command:. The following example redeploys myApp application using the plan. You can then use the progress variable to access the state of the redeploy command. Starts an application, making it available to users. The application must be fully configured and available in the WebLogic domain.
The specified partition must already exist before executing the startApplication command. The following example starts the BigApp application with the specified deployment options. You can then use the progress variable to access the state of the startApplication command.
Stops an application, making it unavailable to users. The specified partition must already exist before executing the stopApplication command. You can then use the progress variable to check whether stopApplication command is running.
The undeploy command returns a WLSTProgress object that you can access to check the status of the command. List of the target servers from which the application will be removed. If not specified, defaults to all current targets. The specified resource group template must already exist before executing the undeploy command.
The specified partition must already exist before executing the undeploy command. The following example removes the businessApp application from all target servers. WLST waits 60, ms for the process to complete.
Updates an application configuration using a new deployment plan. Name of the new deployment plan file. The specified resource group template must already exist before executing the updateApplication command.
The specified partition must already exist before executing the updateApplication command. The following example updates the application configuration for BigApp using the plan.
You can then use the progress variable to access the state of the updateApplication command. Poll for live data matching the Harvester configuration for a particular WLDF system resource and dump it to a local file.
Activates a debug patch on the specified targets. While connected to the Administration Server, the optional target parameter can be specified to activate the debug patch on multiple Managed Servers and clusters.
If the target parameter is not specified, the debug patch will be activated only on the connected server. The activateDebugPatch command returns an array of tasks, each element corresponding to the activation activity on an affected target server instance.
Name of the debug patch to be activated. The patch must exist at the applicable target servers. Use the listDebugPatches command to view the list of available and active patches on the target servers. If not specified, the debug patch will be activated at the system level. The default value is None. This option is ignored if the app option is set to None and the debug patch is activated at the system level.
A comma-separated list of server names, cluster names, or both where the debug patch will be activated. Server —Administration Server only. The name of the target server. Target —Administration Server only. A comma-separated list of server names, cluster names, or both.
The default value is the current directory. The following example captures a diagnostic image on the server, myserver , and members of the cluster, Cluster-0 , and retrieves it on the client:. The following example captures a diagnostic image on the specified partition and retrieves it on the client:. Creates a diagnostics resource from a diagnostic descriptor file without changing the domain configuration.
Note that the resource remains in memory only until the server is shut down; the resource is not deployed the next time the server is booted. That is, this command effects a run-time change only, not a configuration change.
Note: The resource must be enabled separately through the enableSystemResource function, and the features in the resource itself must be enabled. The target server name. Target —A comma-separated list of server names, cluster names, or both. Note that the resource can be enabled or disabled separately by using the enableSystemResource and disableSystemResource commands.
Note also that the features in the resource must be enabled in order to be active. The following example creates a system resource control called myExternalResource from the diagnostic descriptor file mywldf.
The resource control is not enabled. The following example creates and enables a system resource control called myExternalResource from the diagnostic descriptor file mywldf. Because no targets are specified, the target defaults to the currently connected server.
Deactivates all debug patches on the specified targets. While connected to the Administration Server, the optional target parameter can be specified to deactivate all debug patches on multiple Managed Servers and clusters.
If the target parameter is not specified, the debug patches only on the connected server will be deactivated. The deactivateAllDebugPatches command returns an array of tasks, each element corresponding to the deactivation activity on an affected target server instance.
Administration Server only. A comma-separated list of server names, cluster names, or both on which the debug patches will be deactivated. If not specified, the debug patches only on the connected server will be deactivated. The following example deactivates all debug patches on the cluster myCluster. Deactivates a debug patch on the specified targets.
While connected to the Administration Server, the optional target parameter can be specified to deactivate the debug patch on multiple Managed Servers and clusters. If the target parameter is not specified, the debug patch only on the connected server will be deactivated. The deactivateDebugPatches command returns an array of tasks, each element corresponding to the deactivation activity on an affected target server instance.
If not specified, the debug patch will be deactivated at the system level. This option is ignored if the app option is set to None and the debug patch is deactivated at the system level. The following example deactivates a list of debug patches within the scope of an application myapp , in the partition myPartition , on the cluster myCluster.
Destroys a diagnostics resource that was deployed from an external descriptor using the createSystemResourceControl function. To disable a diagnostics resource without destroying it, use the disableSystemResource command. The name of the server on which the resource is currently deployed. Target —A comma-separated list of server names, cluster names, or both on which the resource is currently deployed.
The following example destroys a diagnostics system resource control called myExternalResource that was deployed on the myserver server. The following example deactivates a diagnostics system resource called mySystemResource that is activated on the myserver server.
Polls for live diagnostics data matching the Harvester configuration for a particular WLDF system resource at the specified frequency and duration, and dumps it to a local file.
The data is written in CSV format. If WLDF detects a change in the set of data collected between successive sampling periods, a new output file is created and an informational message is displayed. The creation of multiple output files can result if the sampling interval is particularly long. You can merge these data files using the mergeDiagnosticData command. The name of the server on which the system resource is running. The following example activates the diagnostic system resource mySystemResource on the myServer server.
Executes a query against the specified log file. The default output format is XML. Comma-separated list of export diagnostic options, specified as name-value pairs. This option defaults to 0. This option defaults to Long. This option defaults to export. This option defaults to ServerLog. This option defaults to myserver. This option defaults to ". This option defaults to "" empty string , which returns all data. This option defaults to.. The supported formats are xml , txt and csv.
The default format is xml. When specified, the beginTimestamp and endTimestamp options are ignored. You can specify any combination of day, hour, and minute components in any order. The following example executes a query against the ServerLog named myserver. This command requires that you have a secure connection to the Managed Server. This option can be used only if you are currently connected to the Administration Server.
By default, data is retrieved only from the server to which WLST is connected. Exports harvested metric data from the diagnostic archive for a particular server-scoped or partition-scoped WLDF system resource.
If not specified, the data will be retrieved from the server to which WLST is connected. For example, 1d 5h 30m specifies data that is one day, five hours and 30 minutes old. SimpleDateFormat syntax in which the timestamp for the harvested data is rendered. The following example exports the harvested diagnostic data from the WLDF system resource, wldf-1 running on the myserver server, and writes the data to the file named export.
Exports the harvested metric data from the diagnostic archive for a WLDF system resource in the offline mode when the server is not running. SimpleDateFormat pattern string in which the timestamp for harvested data is rendered. The following example exports the harvested diagnostic data from the WLDF system resource, wldf-1 in offline mode, and writes the data to the file named export.
Returns, as an array of strings, a list of the previously captured diagnostic images that are stored in the image destination directory configured on the server. This command is useful for identifying a diagnostic image capture that you want to download, or for identifying a diagnostic image capture from which you want to download a specific entry. Gets the logical names of diagnostic data accessor instances currently available on a server or partition, and returns them as an array of string values.
If not specified, the data will be retrieved from the current server to which WLST is connected. The following example retrieves the diagnostic data accessor names from myserver server and returns them as an array of string values. The following example lists the active and available debug patches on the cluster myCluster.
The columns labeled ms1 and ms2 list the active and available patches deployed on Managed Servers ms1 and ms2 , respectively. For example, to display information about the disconnect command, enter the following command:.
You can create a WLST script. For more information about Ant, see the Apache Ant 1. The wlst task is predefined in the version of Ant that is installed with WebLogic Server.
If you want to use the wlst task with your own Ant installation, include the following task definition in your build file:. Name and location of a properties file that contains name-value pairs that you can reference in your WLST script. Name and location of the WLST script file that you would like to execute. If the specified WLST script file does not exist, this task fails. List of arguments to pass to the script. These arguments are accessible using the sys.
This attribute defaults to true , specifying that the embedded script is invoked first. Boolean value that specifies whether ant property expansion will work in the specified WLST script. This element is the standard Ant classpath element.
You can specify a reference to a path element that you have defined elsewhere in the build file or nest elements that specify the files and directories to add to the class path. See "Path-like Structures" in Apache Ant 1.
The following sections show examples for the createServer , loop , and error targets. In the following example, the createServer target does the following:. Executes the script in the nested script element. Executes the script file myscript. The script file is located in the directory from which you started Ant.
You could use such a file to start an edit session, create a new server, save, and activate the configuration changes. Defines three arguments that are passed to the script. Executes the WLST script file myscript. Executes the embedded script to print the variable, thisWillCauseNameError. The main steps include converting WLST definitions and method declarations to a. When running recorded scripts directly in a Jython interpreter, Boolean values of true and false can cause an error.
Before running recorded scripts in a Jython interpreter, make one of the following changes to the script:. Change true and false values to wl. You can customize the default WLST home directory by passing the following argument on the command line:. Table describes ways to customize WLST. A JAR file, jython-modules. Use addHelpCommandGroup to add a command group to the list of command groups that are displayed by the help command.
Use addHelpCommand to add a command to the list of commands that is displayed by the help 'commandGroup' command. To add integrated help, you define the help text for each command group and command in a resource bundle, which can be either a class or a property resource file.
You can define the help for multiple command groups in the same resource bundle. For example, the following lines define the short description and description for the command group navigate :. When you enter the help command to display a list of command groups, the short description for navigate is displayed in the listing:. When you enter the help 'navigate' command, the description is displayed above the list of commands in the group:.
The resource bundle contains help text entries for commands using a standard pattern. For each command name, there are several entries:. The short description is shown to the right of the command name when you enter the help ' commandGroup ' command to list all commands in a group:. The description, example, and syntax are displayed when you enter the help ' commandName ' command:. After defining the help text in the resource bundle, use addHelpCommandGroup to add the command group name to the list of command groups output by the help command.
Use addHelpCommand to add each command in a group to the list of commands displayed by the help ' commandGroup ' command. Within this script, the wlstHomeSample command is defined, which prints a text string:. When defining new WLST commands in this way, store the. The script has the same structure as the previous example. Within this script, the wlstExampleCmd command is defined, which prints a text string:.
Note that you must create the WLST lib directory if it does not already exist. Previous Next JavaScript must be enabled to correctly display this content. It is based on the Java scripting interpreter, Jython.
0コメント