weblogic.Server Command-Line Reference

2 weblogic.Server Command-Line Reference

The weblogic.Server class is the main class for a WebLogic Server instance. You start a server instance by invoking weblogic.Server in a Java command.You can invoke the class directly in a command prompt (shell), indirectly through scripts, or through Node Manager.

Oracle recommends using java weblogic.Server primarily for initial development but not as a standard mechanism for starting production systems for the following reasons:

java weblogic.Server will not function if you select a product directory outside of the ORACLE_HOME directory.
When executing java weblogic.Server, patches will not be recognized by the WebLogic Server run time.

The following sections explain how to use the weblogic.Server class to start WebLogic Server:

For information about using scripts to start an instance of WebLogic Server, see Starting an Administration Server with a Startup Script and Starting Managed Servers With a Startup Script in Administering Server Startup and Shutdown for Oracle WebLogic Server.

For information about using the Node Manager to start an instance of WebLogic Server, see Using Node Manager to Control Servers in the Administering Node Manager for Oracle WebLogic Server.

Required Environment and Syntax for weblogic.Server

Before you can use the weblogic.Server class to start a WebLogic Server instance, you must install WebLogic Server, set the CLASSPATH environment variable, and include a Java Virtual Machine (JVM) in your PATH environment variable.

Environment

To set up your environment for the weblogic.Server command:

Install and configure the WebLogic Server software, as described in Installing and Configuring Oracle WebLogic Server and Coherence.
If desired, modify the CLASSPATH environment variable, as described in Modifying the Classpath.
Include a Java Virtual Machine (JVM) in your PATH environment variable. You can use any JVM that is listed in Supported Configurations.

If you do not include a JVM in the PATH environment variable, you must provide a pathname for the Java executable file that the JVM provides.

Modifying the Classpath

After installation, WebLogic Server's classpath is already set, but you may choose to modify it for a number of reasons such as adding a patch to WebLogic Server, updating the version of Derby you are using, or adding support for Log4j logging.

To apply a patch to ALL of your WebLogic Server domains without the need to modify the classpath of a domain, give the patch JAR file the name, weblogic_sp.jar, and copy it into the WL_HOME/server/lib directory. The commEnv.cmd/sh script will automatically include a JAR named weblogic_sp on the classpath for you.

If you would rather not use the name weblogic_sp.jar for your patch file or you would just like to make sure a JAR file, such as one mentioned below, comes before weblogic.jar on the classpath:

For ALL domains, edit the commEnv.cmd/sh script in WL_HOME/common/bin and prepend your JAR file to the WEBLOGIC_CLASSPATH environment variable.
To apply a patch to a SPECIFIC WebLogic Server domain, edit the setDomainEnv.cmd/sh script in that domain's bin directory, and prepend the JAR file to the PRE_CLASSPATH environment variable.

Note:

setDomainEnv is designed to be sourced from other scripts, such as the startWebLogic script. setDomainEnv should not be called directly from within an interactive shell. Doing so can cause unpredictable issues in the domain.

If you use Derby, the open-source all-Java database management system included with Oracle WebLogic Server for use by the sample applications and code examples, include the following files on the classpath:

WL_HOME/common/derby/lib/derbyclient.jar - for the driver on the client side
WL_HOME/common/derby/lib/derbynet.jar and WL_HOME/common/derby/lib/derby.jar - for running the Derby network server

If you use WebLogic Enterprise Connectivity, include the following files on the classpath:

WL_HOME/server/lib/wlepool.jar

WL_HOME/server/lib/wleorb.jar

If you use Log4j logging, include the following file on the classpath:

WL_HOME/server/lib/log4j.jar

Note:

The use of Log4j with the WebLogic logging service, as an alternative to Java logging, is deprecated as of WebLogic Server 12.1.3.

The shell environment in which you run a server determines which character you use to separate path elements. On Windows, you typically use a semicolon (;). In a BASH shell, you typically use a colon (:).

Syntax

The syntax for invoking weblogic.Server is as follows:

java [options] weblogic.Server [-help]

The java weblogic.Server -help command returns a list of frequently used options.

Default Behavior

Understand the default sequence of operations that occur when a WebLogic Server instance is started without any options having been passed to the weblogic.Server class.

If you have set up the required environment described in Environment, when you enter the command java weblogic.Server with no options, WebLogic Server does the following:

Looks in the domain_name/config directory for a file named config.xml.
If config.xml exists in the domain_name/config directory, WebLogic Server does the following:
1. If only one server instance is defined in config/config.xml, it starts that server instance.
  
  For example, if you issue java weblogic.Server from ORACLE_HOME\user_projects\domains\medrec, WebLogic Server starts the MedRec server.
2. If there are multiple server instances defined in config/config.xml:
  - If an Administration Server is defined, it looks for the server with that name.
  - If an Administration Server is not defined, it looks for a server configuration named myserver. If it finds such a server configuration, it starts the myserver instance.
  - If it does not find a server named myserver, WebLogic Server exits the weblogic.Server process and generates an error message.
If there is no config.xml file in the current directory, WebLogic Server prompts you to create one. If you respond y, WebLogic Server does the following:
1. Creates a server configuration named myserver, and persists the configuration in a file named config/config.xml.
  
  Any options that you specify are persisted to the config.xml file. For example, if you specify -Dweblogic.ListenPort=8001, then WebLogic Server saves 8001 in the config.xml file. For any options that you do not specify, the server instance uses default values.
  
  You can configure WebLogic Server to make backup copies of the configuration files. This facilitates recovery in cases where configuration changes need to be reversed or the unlikely case that configuration files become corrupted. See Configuration File Archiving in Understanding Domain Configuration for Oracle WebLogic Server.
2. Uses the username and password that you supply to create a user with administrative privileges. It stores the definition of this user along with other basic, security-related data in domain_name/security files named DefaultAuthenticatorInit.ldift, DefaultRoleMapperInit.ldift, and SerializedSystemIni.dat.
  
  WebLogic Server also encrypts and stores your username and password in a server_name/security/boot.properties file, which enables you to bypass the login prompt during subsequent instantiations of the server. See Boot Identity Files in Administering Server Startup and Shutdown for Oracle WebLogic Server.
3. Creates two scripts, bin/startWebLogic.cmd and bin/startWebLogic.sh, which you can use to start subsequent instantiations of the server. You can use a text editor to modify startup options such as whether the server starts in production mode or development mode. The startWebLogic script contains comments that describe each option.
Note that the server starts as an Administration Server in a new domain. There are no other servers in this domain, nor are any of your deployments or third-party solutions included. You can add them as you would add them to any WebLogic domain.

weblogic.Server Configuration Options

You can use weblogic.Server options to configure the attributes of a server instance. The following attributes are commonly used when starting a server instance:

WebLogic Server provides other startup options that enable you to temporarily override a server's saved configuration. For information about these startup options, see Options that Override a Server's Configuration.

Unless you are creating a new domain as described in Using the weblogic.Server Command Line to Create a Domain, all startup options apply to the current server instantiation; they do not modify the persisted values in an existing config.xml file. Use the WebLogic Server Administration Console or WebLogic Scripting Tool (WLST) to modify the config.xml file. See Creating Domains Using WLST Offline in Understanding the WebLogic Scripting Tool.

For information on verifying the WebLogic Server attribute values that you set, see Verifying Attribute Values That Are Set on the Command Line.

JVM Parameters

Table 2-1 describes frequently used options that configure the Java Virtual Machine (JVM) in which the server instance runs. For a complete list of JVM options, see the documentation for your specific JVM. For a list of JVMs that can be used with WebLogic Server, see Supported Configurations.

Table 2-1 Frequently Used Options for Setting JVM Parameters

Option	Description
`-Xms and -Xmx`	Specify the minimum and maximum values (in megabytes) for Java heap memory. For example, you might want to start the server with the default allocation of 256 megabytes of Java heap memory to the WebLogic Server. To do so, start the server using the `java -Xms256m` and `-Xmx512m` options. The values assigned to these parameters can dramatically affect the performance of your WebLogic Server and are provided here only as general defaults. In a production environment you should carefully consider the correct memory heap size to use for your applications and environment.
`-classpath`	The minimum content for this option is described under Modifying the Classpath. Instead of using this argument, you can use the `CLASSPATH` environment variable to specify the classpath.
`-client -server`	Used by some JVMs to start a HotSpot virtual machine, which enhances performance. For a list of JVMs that can be used with WebLogic Server, see Supported Configurations.
`-Dfile.encoding=Canonical Name weblogic.Server`	To display special characters on Linux browsers, set the JVM `file.encoding` system property to `ISO8859_1`. For example: `java -Dfile.encoding=ISO8859_1 weblogic.Server` For a complete listing, see the Supported Encodings page available at `http://docs.oracle.com/javase/7/docs/technotes/guides/intl/encoding.doc.html`.

Location of Configuration Data

All server instances must have access to configuration data. Table 2-2 provides options for indicating the location of this data.

Table 2-2 Options for Indicating the Location of Configuration Data

Option	Description
`-Dweblogic.home=WL_HOME`	Specifies the location of the WebLogic home directory, which contains essential information. By default, `weblogic.Server` determines the location of the WebLogic home directory based on values in the classpath.
`-Dweblogic.RootDirectory=path`	Specifies the server's root directory. See A Server's Root Directory in Understanding Domain Configuration for Oracle WebLogic Server. By default, the root directory is the directory from which you issue the start command.
`-Dweblogic.management.GenerateDefaultConfig=true`	Prevents the `weblogic.Server` class from prompting for confirmation when creating a `config.xml` file. Valid only if you invoke `weblogic.Server` in an empty directory. See Default Behavior.
`-Dweblogic.Domain=domain`	Specifies the name of the domain. If you are using `weblogic.Server` to create a domain, you can use this option to give the domain a specific name. In addition, this option supports a directory structure that WebLogic Server required in releases prior to 7.0 and continues to support in current releases. Prior to 7.0, all configuration files were required to be located in the following pathname: `.../config/domain_name/config.xml` In this pathname, `domain_name` is the name of the domain. If your domain's configuration file conforms to that pathname, and if you invoke the `weblogic.Server` command from a directory other than `config/domain_name`, you can include the `-Dweblogic.Domain=domain` argument to cause WebLogic Server to search for a `config.xml` file in a pathname that matches `config/domain_name/config.xml`.

For information on how a Managed Server retrieves its configuration data, see the -Dweblogic.management.server entry in Table 2-3.

The WebLogic Server Administration Console does not display values that you set on the command line. For information on verifying the attribute values that you set, see Verifying Attribute Values That Are Set on the Command Line.

Example

The following example starts a Managed Server instance named SimpleManagedServer. Specifying a config.xml file is not valid because Managed Servers contact the Administration Server for their configuration data. Multiple instances of WebLogic Server can use the same root directory. However, if your server instances share a root directory, make sure that all relative filenames are unique. In this example, SimpleManagedServer shares its root directory with SimpleServer. The command itself is issued from the D:\ directory after running WL_HOME\server\bin\setWLSEnv.cmd:

D:\> java -Dweblogic.Name=SimpleManagedServer 
 -Dweblogic.management.server=http://localhost:7001
 -Dweblogic.RootDirectory=c:\my_domains\SimpleDomain weblogic.Server

Options that Override a Server's Configuration

In most cases, you do not use startup options to override the configuration that is saved in the domain's config.xml file. However, in some extraordinary cases you might need to do so.

Tip:

When you use a startup option to override a configuration value, the server instance uses this value for the duration of its life cycle. Even if you use the WebLogic Server Administration Console, the WebLogic Scripting Tool, or some other utility to change the value in the configuration, the value will remain overridden until you restart the server without using the override.

For example, in a production environment, your organization might have a policy against modifying the domain's config.xml file, but you need to shut down the Administration Server and restart it using a temporary listen port. In this case, when you use the weblogic.Server command to start the Administration Server, you can include the -Dweblogic.ListenPort=7501 startup option to change the listen port for the current server session. The server instance initializes its configuration MBeans from the config.xml file but substitutes 7501 as the value of its listen port. When you subsequently restart the server without passing the startup option, it will revert to using the value from the config.xml file, 8010. (See Figure 2-1.)

Figure 2-1 Overriding config.xml Values

Description of "Figure 2-1 Overriding config.xml Values"

The following options temporarily override a server's configuration:

Server Communication

Table 2-3 describes the options for configuring how servers communicate.

Table 2-3 Options for Configuring Server Communication

Option	Description
`-Dweblogic.management.server=[protocol://]Admin-host:port`	Starts a server instance as a Managed Server and specifies the Administration Server that will configure and manage the server instance. The domain's configuration file does not specify whether a server configuration is an Administration Server or a Managed Server. You determine whether a server instance is in the role of Administration Server or Managed Server with the options that you use to start the instance. If you omit the `-Dweblogic.management.server` option in the start command, the server starts as an Administration Server (although within a given domain, there can be only one active Administration Server instance). Once an Administration Server is running, you must start all other server configurations as Managed Servers by including the `-Dweblogic.management.server` option in the start command. For `protocol`, specify `HTTP`, `HTTPS`, `T3`, or `T3S`. The `T3S` and `HTTPS` protocols require you to enable SSL on the Managed Server and the Administration Server and specify the Administration Server's SSL listen port. Note: Regardless of which protocol you specify, the initial download of a Managed Server's configuration is over HTTP or HTTPS. After the RMI subsystem initializes, the server instance can use the T3 or T3S protocol. For `Admin-host`, specify localhost or the DNS name or IP address of the machine where the Administration Server is running. For `port`, specify the Administration Server's listen port. If you set up the domain-wide administration port, `port` must specify the domain-wide administration port. See Configuring Managed Server Connections to the Administration Server in Administering Server Startup and Shutdown for Oracle WebLogic Server.
`-Dweblogic.ListenAddress=host`	Specifies the address at which this server instance listens for requests. The `host` value must be either the DNS name or the IP address of the computer that is hosting the server instance. This startup option overrides any listen address value specified in the `config.xml` file. The override applies to the current server instantiation; it does not modify the value in the `config.xml` file. Use any of the administration tools listed in Summary of System Administration Tools and APIs in Understanding Oracle WebLogic Server to modify the `config.xml` file. See Configure listen addresses in the Oracle WebLogic Server Administration Console Online Help and Creating Domains Using WLST Offline in Understanding the WebLogic Scripting Tool.
`-Dweblogic.ListenPort=portnumber`	Enables and specifies the plain-text (non-SSL) listen port for the server instance. This startup option overrides any listen port value specified in the `config.xml` file. The override applies to the current server instantiation; it does not modify the value in the `config.xml` file. Use any of the administration tools listed in Summary of System Administration Tools and APIs in Understanding Oracle WebLogic Server to modify the `config.xml` file. The default listen port is 7001. See Configure listen ports in the Oracle WebLogic Server Administration Console Online Help and Creating Domains Using WLST Offline in Understanding the WebLogic Scripting Tool.
`-Dweblogic.ssl.ListenPort=portnumber`	Enables and specifies the port at which this WebLogic Server instance listens for SSL connection requests. This startup option overrides any SSL listen port value specified in the `config.xml` file. The override applies to the current server instantiation; it does not modify the value in the `config.xml` file. Use any of the administration tools listed in Summary of System Administration Tools and APIs in Understanding Oracle WebLogic Server to modify the `config.xml` file. The default SSL listen port is 7002. See Configure listen ports in the Oracle WebLogic Server Administration Console Online Help and Creating Domains Using WLST Offline in Understanding the WebLogic Scripting Tool.
`-Dweblogic.management.discover={true\|false}`	Note: This option was removed as of WebLogic Server 9.0. Determines whether an Administration Server recovers control of a domain after the server fails and is restarted. A `true` value causes an Administration Server to communicate with all known Managed Servers and inform them that the Administration Server is running. A false value prevents an Administration Server from communicating with any Managed Servers that are currently active in the domain. Tip: Specify `false` for this option only in the development environment of a single server. Specifying `false` can cause server instances in the domain to have an inconsistent set of deployed modules. In WebLogic Server 9.0, this command is deprecated because if an Administration Server stops running while the Managed Servers in the domain continue to run, each Managed Server will periodically attempt to reconnect to the Administration Server at the interval specified by the `ServerMBean` attribute `AdminReconnectIntervalSecs`. See Administering Server Startup and Shutdown for Oracle WebLogic Server.

SSL

Each Weblogic Server instance uses an instance of weblogic.management.configuration.SSLMBean to represent its SSL configuration.

All of the options in the following table that start with -Dweblogic.security.SSL modify the configuration of the server's SSLMBean. For example, the -Dweblogic.security.SSL.ignoreHostnameVerification option sets the value of the SSLMBean's ignoreHostnameVerification attribute.

Table 2-4 describes the options for configuring a server to communicate using Secure Sockets Layer (SSL).

Note:

As of WebLogic Server version 12.1.1, JSSE is the only SSL implementation that is supported. The Certicom-based SSL implementation is removed and is no longer supported in WebLogic Server.

Table 2-4 Options for Configuring SSL

Option	Description
`-Dweblogic.security.SSL.ignoreHostnameVerification=true`	Disables host name verification, which enables you to use the demonstration digital certificates that are shipped with WebLogic Server. By default, when a WebLogic Server instance is in the role of SSL client (it is trying to connect to some other server or application via SSL), it verifies that the host name that the SSL server returns in its digital certificate matches the host name of the URL used to connect to the SSL server. If the host names do not match, the connection is dropped. If you disable host name verification, either by using this option or by modifying the server's configuration in the `config.xml` file, the server instance does not verify host names when it is in the role of SSL client. Note: Oracle does not recommend using the demonstration digital certificates or turning off host name verification in a production environment. This startup option overrides any host name verification setting in the `config.xml` file. The override applies to the current server instantiation; it does not modify the value in the `config.xml` file. Use the WebLogic Server Administration Console or WLST to modify the `config.xml` file. See Using Host Name Verification in Administering Security for Oracle WebLogic Server.
`-Dweblogic.security.SSL.HostnameVerifier=hostnameverifierimplementation`	Specifies the name of a custom host name verifier class. The class must implement the `weblogic.security.SSL.HostnameVerifier` interface.
`-Dweblogic.security.SSL.sessionCache.ttl=sessionCacheTimeToLive`	Modifies the default server-session time-to-live for SSL session caching. The `sessionCacheTimeToLive` value specifies (in milliseconds) the time to live for the SSL session. The default value is 90000 milliseconds (90 seconds). This means if a client accesses the server again (via the same session ID) within 90 seconds, WebLogic Server will use the existing SSL session. You can change this value by setting `-Dweblogic.security.SSL.sessionCache.ttl` in the server startup script. For `sessionCache.ttl`: The minimum value is `1` The maximum value is `Integer.MAX_VALUE` The default value is `90000`
`-Dweblogic.security.SSL.CertificateCallback=callback-handler`	Specifies a certificate callback handler class, which evaluates details contained the end-user certificate passed in a secure connection request to WebLogic Server. Depending on the details contained in the certificate, the callback handler returns a `true` or `false`, which determines whether authentication is successful. Note: If you use a certificate callback implementation in WebLogic Server, a callback is generated whenever a request is received over a secure port. As a result, using certificate callbacks may impose a performance overhead that should be taken into consideration. See Checking the Validity of End User Certificates in Administering Security for Oracle WebLogic Server.
`-Dweblogic.management.pkpassword=pkpassword`	Specifies the password for retrieving SSL private keys from an encrypted flat file. Use this option if you store private keys in an encrypted flat file.
`-Dweblogic.security.SSL.trustedCAKeyStore=path`	Specifies the trusted keystore to use in either of these use cases: Starting a Managed Server that downloads the initial configuration from the Administration Server over SSL Running a WebLogic client, such as WLST, that connects to a WebLogic Server server instance over SSL The `path` value must be the full path to the JKS or PKCS12 trust keystore file. Note that if the keystore is type PKCS12, then a password is required. You can specify the password using the `-Dweblogic.security.SSL.trustedCAkeystorePassPhrase` as described below. Oracle recommends that you do not use the demonstration certificate authorities in any type of production deployment. See Configuring SSL in Administering Security for Oracle WebLogic Server.
`-Dweblogic.security.SSL.trustedCAkeystorePassPhrase=password`	Specifies the password to use if you specified a PKCS12 trust keystore using the `-Dweblogic.security.SSL.trustedCAKeyStore` property. The password is not necessary for JKS trust keystores. When running a WebLogic client such as WLST, if the type of trust keystore specified by `-Dweblogic.security.SSL.trustedCAkeystore` is not JKS (for example, it is PKCS12) and you do not specify the `-Dweblogic.security.SSL.trustedCAkeystorePassPhrase` property, then WebLogic prompts you to enter the password.
`-Dsecurity.use.interopCA=true`	If you are using WebLogic Server together with a version of WebLogic Server prior to 12.1.2, be aware that the demo trust keystore of the previous versions does not contain the demo CA certificate used as of version 12.1.2. Therefore, if an instance of WebLogic Server sends its public certificate to an instance of WebLogic Server running a prior version, that public certificate will not automatically be trusted. Use this system property to generate interoperable demo certificates signed by the previous demo CA certificate.
`-Dweblogic.security.SSL.protocolVersion=protocol`	Specifies the protocol that is used for SSL connections. The `protocol` value can be one of the following: `SSL3` — Only SSL v3.0 messages are sent and accepted. `TLS1` — Enables any protocol starting with TLS for messages that are sent and accepted; for example, TLS v1.0, TLS v1.1, TLS v1.2, and TLS v1.3. Note: WebLogic Server supports TLS v1.3 only with JDK 11 and JDK 8 Update 261 (JDK 8u261) or later. If you are running an earlier JDK version, then TLS v1.3 may not be available. Support for TLS v1.0 and v1.1 is deprecated. Oracle strongly recommends that you do not use TLS v1.0 and v1.1. In addition, these versions may be disabled by default in certain JDK updates by the underlying JSSE provider. `ALL` — Depends on the JSSE provider and JDK version. (This is the default.) See Using the weblogic.security.SSL.protocolVersion System Property in Administering Security for Oracle WebLogic Server.
`-Dweblogic.security.SSL.minimumProtocolVersion=protocol`	Specifies the minimum protocol version that is used for SSL connections. The `protocol` value can be one of the following: `SSLv3` — Specifies SSL v3.0 as the minimum protocol version enabled in SSL connections. `TLSv1` — Specifies TLS v1.0 as the minimum protocol version enabled in SSL connections. `TLSvx.y` — Specifies TLS vx.y as the minimum protocol version enabled in SSL connections, where x is between 1 and 9, and y is between 0 and 9, inclusive. Note: TLS v1.2 is the default minimum protocol version configured in WebLogic Server. Oracle recommends the use of TLS v1.2 or later in a production environment. WebLogic Server logs a warning if the TLS version is set below 1.2. Support for TLS v1.0 and v1.1 is deprecated. Oracle strongly recommends that you do not use TLS v1.0 and v1.1. In addition, these versions may be disabled by default in certain JDK updates by the underlying JSSE provider. WebLogic Server supports TLS v1.3 only with JDK 11 and JDK 8 Update 261 (JDK 8u261) or later. If you are running an earlier JDK version, then TLS v1.3 may not be available. See Using the weblogic.security.SSL.minimumProtocolVersion System Property in Administering Security for Oracle WebLogic Server.
`-Dweblogic.security.ssl.sslcontext.protocol=protocol`	Specifies the `javax.net.ssl.SSLContext` algorithm for the JSSE provider. For some JSSE providers, there is a correlation between the `javax.net.ssl.SSLContext` algorithm and the initially enabled SSL/TLS protocols. If the JSSE provider configured in your system interprets the protocol parameter differently, you may need to set this property. Refer to the vendor-specific documentation for the correlations between the `javax.net.ssl.SSLContext` setting and the enabled SSL/TLS protocols. Note: When using the IBM JSSE provider, WebLogic Server attempts to select a `javax.net.ssl.SSLContext` algorithm equivalent to the default `TLS`. Standard supported values are `SSL`, `SSLv3`, `TLS` (the default), `TLSv1`, `TLSv1.1`, `TLSv1.2`, and `TLSv1.3`. WebLogic Server does not support `SSLv2`. Note that support for TLSv1.3 is available only with JDK 11and JDK 8 Update 261 (JDK 8u261) or later. For earlier JDK versions, TLS v1.3 may not be available. See Using the weblogic.security.ssl.sslcontext.protocol System Property in Administering Security for Oracle WebLogic Server.

Setting Additional SSL Attributes

To set additional SSL attributes from the startup command, do the following:

To determine which SSL attributes can be configured from startup options, view the WebLogic Server Javadoc for the SSLMBean and ServerMBean, described in MBean Reference for Oracle WebLogic Server. The Javadoc also indicates valid values for each attribute.

Each attribute that SSLMBean and ServerMBean expose as a setter method can be set by a startup option.
To set attributes in the SSLMBean, add the following option to the start command:
-Dweblogic.ssl.attribute-name=value
where attribute-name is the name of the MBean's setter method without the set prefix.
To set attributes in the ServerMBean, add the following option to the start command:
-Dweblogic.server.attribute-name=value
where attribute-name is the name of the MBean's setter method without the set prefix.

For example, the SSLMBean exposes its Enabled attribute with the following setter method:

setEnabled()

To enable SSL for a server instance named MedRecServer, use the following command when you start MedRecServer:

java -Dweblogic.Name=MedRecServer
     -Dweblogic.ssl.Enabled=true weblogic.Server

HTTP Strict Transport Security

HTTP Strict Transport Security (HSTS) is a web security policy mechanism that allows a web server to be configured so that web browsers, or other user agents, can access the server using only secure connections, such as HTTPS. Web servers declare this policy using the Strict-Transport-Security HTTP response header field.

For more information about HSTS, see Using HTTP Strict Transport Security in Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server.

Table 2-5 describes the system properties that you add to WebLogic Server domain start up scripts to enable HSTS and customize the response header.

Table 2-5 Options for Configuring HSTS

Option	Description
`-Dweblogic.http.headers.enableHSTS={true\|false}`	Specifies whether the server is configured to use HSTS. The default value of this system property is `false`, indicating that WebLogic Server will NOT send  the HSTS header by default. Set this property to `true` to enable HSTS. When enabled, the following default HSTS header is sent with all responses: `Strict-Transport-Security: max-age=31536000; includeSubDomains; preload` The values specified in this response are the minimum values required by the HSTS preload submission web site `https://hstspreload.org/`. You can customize these values using the system properties described in the following rows of this table.
`-Dweblogic.http.headers.hsts.maxage=max-age-seconds`	Specifies the time, in seconds, that the browser remembers that a site is only to be accessed using HTTPS. The default value is 31536000 seconds (one year).
`-Dweblogic.http.headers.hsts.includesubdomains={true\|false}`	Specifies whether the HSTS policy applies to this HSTS host as well as any subdomains of the host's domain name. If this directive is not specified, the property defaults to `true` and is included in the header response.
`-Dweblogic.http.headers.hsts.preload={true\|false}`	Specifies that the site is requesting inclusion in the HTTP Strict Transport Security (HSTS) preload list, which is a list of sites that are hardcoded into Chrome (and other browsers) as using HTTPS only. If this directive is not specified, the property defaults to `true` and is included in the header response. Ensure that your site meets all the necessary requirements before including the `preload` directive in your response header. To ensure your site is successfully preloaded, request submission at `https://hstspreload.org/`.

Security

Table 2-6 describes the options for configuring general security parameters.

Table 2-6 Options for General Security Parameters

Option	Description
-`Dweblogic.management.username=username`	Specifies the username under which the server instance will run. As of WebLogic Server 12.1.1, the boot username property `weblogic.management.username` has been deprecated and will be removed in a future release, and you will no longer be able to specify the username in the command for starting WebLogic Server in production mode. As an alternative, Oracle recommends that you use the `boot.properties` file to specify the boot username for WebLogic Server. See Boot Identity Files in Administering Server Startup and Shutdown for Oracle WebLogic Server. See Provide User Credentials to Start and Stop Servers in Administering Server Startup and Shutdown for Oracle WebLogic Server.
`-Dweblogic.management.password=password`	Specifies the user password. As of WebLogic Server 12.1.1, the boot password system property `weblogic.management.password` has been deprecated and will be removed in a future release, and you will no longer be able to specify the password in the command for starting WebLogic Server in production mode. As an alternative, Oracle recommends that you use the `boot.properties` file to specify the boot password for WebLogic Server. See Boot Identity Files in Administering Server Startup and Shutdown for Oracle WebLogic Server. See Provide User Credentials to Start and Stop Servers in Administering Server Startup and Shutdown for Oracle WebLogic Server.
`-Dweblogic.system.StoreBootIdentity=true`	Creates a `boot.properties` file in the server's root directory. The file contains the username and an encrypted version of the password that was used to start the server. Do not specify this argument in a server's `ServerStartMBean`. See Specifying User Credentials When Starting a Server with the Node Manager in Administering Server Startup and Shutdown for Oracle WebLogic Server. Oracle recommends that you do not add this argument to a startup script. Instead, use it only when you want to create a `boot.properties` file. See Boot Identity Files in Administering Server Startup and Shutdown for Oracle WebLogic Server.
`-Dweblogic.system.BootIdentityFile=filename`	Specifies a boot identity file that contains a username and password. The `filename` value must be the fully qualified pathname of a valid boot identity file. For example: `-Dweblogic.system.BootIdentityFile= WL_HOME\mydomain\servers\myserver\security \boot.properties` If you do not specify a filename, a server instance, or the WLST `SHUTDOWN` command, use the `boot.properties` file in the server's root directory. If there is no boot identity file, when starting a server, the server instance prompts you to enter a username and password.
`-Dweblogic.system.RemoveBootIdentity=true`	Removes the boot identity file after a server starts.
`-Dweblogic.security.anonymousUserName=name`	Assigns a user ID to anonymous users. By default, all anonymous users are identified with the string `<anonymous>`. To emulate the security behavior of WebLogic Server 6.x, specify `guest` for the `name` value and create a user named `guest` in your security realm. See Users, Groups, and Security Roles in Securing Resources Using Roles and Policies for Oracle WebLogic Server.
`-Djava.security.manager` `-Djava.security.policy[=]=filename`	Standard Java EE options that enable the Java Security Manager and specify a filename (using a relative or fully-qualified pathname) that contains Java 2 security policies. To use the WebLogic Server sample policy file, specify `WL_HOME\server\lib\weblogic.policy`. Using `-Djava.security.policy==filename` (note the double equal sign (`==`)) causes the policy file to override any default security policy. When JACC is enabled, this property causes WebLogic Server to ignore any policy files that are used for servlet and EJB authorization. A single equal sign (`=`) causes the policy file to be appended to an existing security policy. Note: The WebLogic JACC provider does not require the Java Security Manager to be enabled. See Using the Java Security Manager to Protect WebLogic Resources in Developing Applications with the WebLogic Security Service.
`-Dweblogic.security.fullyDelegateAuthorization=true`	By default, roles and security policies cannot be set for an EJB or Web application through the WebLogic Server Administration Console unless security constraints were defined in the deployment descriptor for the EJB or Web application. Use this option when starting WebLogic Server to override this problem. This startup option does not work with EJBs or EJB methods that use `<unchecked>` or `<restricted>` tags or Web applications that do not have a role-name specified in the `<auth-constraint>` tag.
`-Dweblogic.management.anonymousAdminLookupEnabled=true`	Enables you to retrieve an `MBeanHome` interface without specifying user credentials. The `MBeanHome` interface is part of the WebLogic Server JMX API. If you retrieve `MBeanHome` without specifying user credentials, the interface gives you read-only access to the value of any MBean attribute that is not explicitly marked as protected by the Weblogic Server MBean authorization process. This startup option overrides the Anonymous Admin Lookup Enabled setting on the domain_name > Security > General page in the WebLogic Server Administration Console. By default, the `MBeanHome` API allows access to MBeans only for WebLogic users who are in one of the default security roles. See Users, Groups, an Security Roles in Securing Resources Using Roles and Policies for Oracle WebLogic Server.
`-Dweblogic.security.identityAssertionTTL=seconds`	Configures the number of seconds that the Identity Assertion cache stores a Subject. When using an Identity Assertion provider (either for an X.509 certificate or some other type of token), Subjects are cached within the server. This greatly enhances performance for servlets and EJB methods with `<run-as>` tags as well as for other places where identity assertion is used but not cached (for example, signing and encrypting XML documents). There might be some cases where this caching violates the desired semantics. By default, Subjects remain in the cache for 300 seconds, which is also the maximum allowed value. Setting the value to `-1` disables the cache. Setting a high value generally improves the performance of identity assertion, but makes the Identity Assertion provider less responsive to changes in the configured Authentication provider. For example, a change in the user's group will not be reflected until the Subject is flushed from the cache and recreated.
`-Djavax.security.jacc.PolicyConfigurationFactory.provider= weblogic.security.jacc.simpleprovider .PolicyConfigurationFactoryImpl` `-Djavax.security.jacc.policy.provider= weblogic.security.jacc.simpleprovider .SimpleJACCPolicy` `-Dweblogic.security.jacc.RoleMapperFactory.provider= weblogic.security.jacc.simpleprovider.RoleMapperFactoryImpl`	Defining these three system properties is required to enable the use of the Java Authorization Contract for Containers in the security realm. When these providers are in use, JACC handles authorization decisions for the EJB and servlet containers for external applications. Any other authorization decisions for internal applications are handled by the authorization in the WebLogic Security framework. Note: JACC authorization does not require the use of Java SE security. The WebLogic JACC implementation expects that the policy object is the default `sun.security.provider.PolicyFile` class. When starting, WebLogic Server attempts to locate and instantiate the classes specified by the JACC startup properties and fails if it cannot find or instantiate them (if, for example, the files specified by the startup properties are not valid classes). See Using the Java Authorization Contract for Containers in Developing Applications with the WebLogic Security Service
`-Dweblogic.security.ldap. maxSize=<max bytes>`	Limits the size of the data file used by the embedded LDAP server. When the data file exceeds the specified size, WebLogic Server eliminates from the data file space occupied by deleted entries.
`-Dweblogic.security.ldap.changeLogThreshold=<number of entries>`	Limits the size of the change log file used by the embedded LDAP server. When the change log file exceeds the specified number of entries, WebLogic Server truncates the change log by removing all entries that have been sent to all Managed Servers.
`-Dweblogic.security.providers.authentication.ldap.socketTimeout=seconds`	Sets a timeout value for the LDAP Authentication provider connection to an LDAP server. If multiple LDAP servers are specified in the `LDAPServerMBean.Host` attribute, the socket timeout applies to each individual LDAP server connection attempt that is made. The default value is 0, which sets no socket timeout on connections. Note that the `LDAPServerMBean.ConnectTimeout` attribute sets the timeout limit for all connection attempts that are made. Typically the socket timeout is used in conjunction with the connect timeout and the parallel connect delay. See Configuring Failover for LDAP Authentication Providers in Administering Security for Oracle WebLogic Server.

The WebLogic Server Administration Console does not display values that you set on the command line. See Verifying Attribute Values That Are Set on the Command Line.

Message Output and Logging

Table 2-7 describes options for configuring a server instance's message output.

Table 2-7 Options for Configuring Message Output

Option Description

Option	Description
`-Dweblogic.Stdout="filename"`	Redirects the server and JVM standard output stream to a file. You can specify a pathname that is fully qualified or relative to the WebLogic Server root directory. See Redirect JVM output in the Oracle WebLogic Server Administration Console Online Help.
`-Dweblogic.Stderr="filename"`	Redirects the server and JVM standard error stream to a file. You can specify a pathname that is fully qualified or relative to the WebLogic Server root directory. See Redirecting JVM Output in Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server.
`-Dweblogic.AdministrationMBeanAuditingEnabled={true\|false}`	Determines whether the Administration Server emits configuration auditing log messages when a user changes the configuration or invokes management operations on any resource within a domain. By default, the Administration Server does not emit configuration auditing messages. See Enable configuration auditing in the Oracle WebLogic Server Administration Console Online Help.

-Dweblogic.Stdout="filename"

Redirects the server and JVM standard output stream to a file. You can specify a pathname that is fully qualified or relative to the WebLogic Server root directory.

See Redirect JVM output in the Oracle WebLogic Server Administration Console Online Help.

-Dweblogic.Stderr="filename"

Redirects the server and JVM standard error stream to a file. You can specify a pathname that is fully qualified or relative to the WebLogic Server root directory.

See Redirecting JVM Output in Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server.

-Dweblogic.AdministrationMBeanAuditingEnabled={true|false}

Determines whether the Administration Server emits configuration auditing log messages when a user changes the configuration or invokes management operations on any resource within a domain.

By default, the Administration Server does not emit configuration auditing messages.

See Enable configuration auditing in the Oracle WebLogic Server Administration Console Online Help.

Setting Logging Attributes

Each Weblogic Server instance uses an instance of weblogic.management.configuration.LogMBean to represent the configuration of its logging services.

To set values for LogMBean attributes from the startup command, do the following:

To determine which log attributes can be configured from startup options, see LogMBean in MBean Reference for Oracle WebLogic Server. The Javadoc also indicates valid values for each attribute.

Each attribute that the LogMBean exposes as a setter method can be set by a startup option.
Add the following option to the start command:
```
-Dweblogic.log.attribute-name=value 
```
where attribute-name is the name of the MBean's setter method without the set prefix.

The LogMBean exposes its FileName attribute with the following setter method:

setFileName()

To specify the name of the MedRecServer instance's local log file, use the following command when you start MedRecServer:

java -Dweblogic.Name=MedRecServer
     -Dweblogic.log.FileName="C:\logfiles\myServer.log"
     weblogic.Server

Clusters

Table 2-8 describes options for configuring additional attributes of a cluster.

Table 2-8 Options for Configuring Cluster Attributes

Option Description

Option	Description
`-Dweblogic.cluster.multicastAddress`	Determines the Multicast Address that clustered servers use to send and receive cluster-related communications. By default, a clustered server refers to the Multicast Address that is defined in the `config.xml` file. Use this option to override the value in `config.xml`. Note: The WebLogic Server Administration Console does not display values that you set on the command line. For information on verifying the attribute values that you set, see Verifying Attribute Values That Are Set on the Command Line. Regardless of how you set the Multicast Address, all servers in a cluster must communicate at the same Multicast Address.

-Dweblogic.cluster.multicastAddress

Determines the Multicast Address that clustered servers use to send and receive cluster-related communications. By default, a clustered server refers to the Multicast Address that is defined in the config.xml file. Use this option to override the value in config.xml.

Note: The WebLogic Server Administration Console does not display values that you set on the command line. For information on verifying the attribute values that you set, see Verifying Attribute Values That Are Set on the Command Line.

Regardless of how you set the Multicast Address, all servers in a cluster must communicate at the same Multicast Address.

Deployment

Table 2-9 describes options for configuring additional attributes for deployment.

Table 2-9 Options for Configuring Deployment Attributes

Option Description

Option	Description
`-Dweblogic.deployment.IgnorePrepareStateFailures=true`	Overrides the default deployment behavior by allowing a server to transition to `Running` even with static deployment `Prepare` failures. Note: This server level flag may cause inconsistent deployment behavior within clusters, such as issues with HttpSessionReplication or SFSB replication.

-Dweblogic.deployment.IgnorePrepareStateFailures=true

Overrides the default deployment behavior by allowing a server to transition to Running even with static deployment Prepare failures.

Note: This server level flag may cause inconsistent deployment behavior within clusters, such as issues with HttpSessionReplication or SFSB replication.

Other Server Configuration Options

Table 2-10 describes options for configuring additional attributes of a server instance.

Table 2-10 Options for Configuring Server Attributes

Option	Description
`-Dweblogic.Name=servername`	Specifies the name of the server instance that you want to start. The specified value must refer to the name of a server that has been defined in the domain's `config.xml` file.
`-Dweblogic.ProductionModeEnabled={true\|false}`	This attribute is deprecated in WebLogic Server 9.0. Determines whether a server starts in production mode. A `true` value prevents a WebLogic Server from automatically deploying and updating applications that are in the `domain_name/autodeploy` directory. If you do not specify this option, the assumed value is `false`. To enable production mode, you can use WLST to set `DomainMBean.isProductionModeEnabled` to `true`, or use the WebLogic Server Administration Console. See Change to production mode in the Oracle WebLogic Server Administration Console Online Help. Note: It is recommended that you enable production mode via the WebLogic Server Administration Console, in `config.xml`, or by supplying the `production` argument to startWebLogic script, for example, `startWebLogic.cmd production`. You should only enable production mode from the command line on the Administration Server. Note: It is important to note that when ProductionModeEnabled is set from the command line on the Administration Server, this value is propagated to all Managed Servers.
`-Dweblogic.management.startupMode=MODE`	The argument `MODE` represents either of the following: `STANDBY` — Starts a server and places it in the `STANDBY` state. See Administering Server Startup and Shutdown for Oracle WebLogic Server. To use this startup argument, the domain must be configured to use the domain-wide administration port. See Administration Port and Administrative Channel in Administering Server Environments for Oracle WebLogic Server and Configure the domain-wide administration port in the Oracle WebLogic Server Administration Console Online Help. `ADMIN` — Starts a server and places it in the `ADMIN` state. See Administering Server Startup and Shutdown for Oracle WebLogic Server. Specifying the startup mode startup option overrides any startup mode setting in the `config.xml` file. The override applies to the current server instantiation and in the `config.xml` file. The system property has the highest precedence over the server configuration settings in the `config.xml` and becomes part of edit session changes if starting an edit session via Administration Console or WLST. If a system property is specified on the server startup: The value cannot be changed in the run time. Starting a new edit session can cause the system property value to be persisted in `config.xml`.
`-Dweblogic.apache.xerces.maxentityrefs=numerical-value`	Limits the number of entities in an XML document that the WebLogic XML parser resolves. If you do not specify this option, the XML parser that WebLogic Server installs resolves 10,000 entity references in an XML document, regardless of how many an XML document contains.
`-Dweblogic.jsp.windows.caseSensitive=true`	Causes the JSP compiler on Windows systems to preserve case when it creates output files names. See Using the WebLogic JSP Compiler in Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server.
`-Dweblogic.servlet.optimisticSerialization=true`	When `optimistic-serialization` is turned on, WebLogic Server does not serialize-deserialize context and request attributes upon `getAttribute(name)` when the request is dispatched across servlet contexts. This means that you must make sure that the attributes common to Web applications are scoped to a common parent classloader (application scoped) or you must place them in the system classpath if the two Web applications do not belong to the same application. When `optimistic-serialization` is turned off (default value), WebLogic Server serialize-deserializes context and request attributes upon `getAttribute(name)` to avoid the possibility of ClassCastExceptions. The optimistic-serialization value can also be specified at domain level in the `WebAppContainerMBean`, which applies for all Web applications. The value in weblogic.xml, if specified, overrides the domain level value. The default value is false.
`-Dweblogic.servlet.maxLoggingURILength=length`	By default, when using extended log format in HTTP access logs, the maximum logged URI length is 256 characters. If the URI exceeds that length, the logged URI is truncated. You can use this property to increase the length of the URI that is logged. See DNS Related Fields in Administering Server Environments for Oracle WebLogic Server.
`-Dweblogic.jdbc.qualifyRMName=false`	When set, restores pre-WebLogic Server 11gR1 (10.3.1) behavior of not qualifying the JTA registration name with the domain name.
`-Dweblogic.ScatteredReadsEnabled=true` and `-Dweblogic.GatheredWritesEnabled=true`	When each is set to true, increases efficiency during I/O in environments with high network throughput. These command options are used together to optimize WebLogic Server performance for use with Oracle Exalogic. See the Oracle Exalogic Enterprise Deployment Guide.
`-Dweblogic.replication.enableLazyDeserialization= true`	When set to true, increases efficiency with session replication. This command option is used to optimize WebLogic Server performance for use with Oracle Exalogic. See the Oracle Exalogic Enterprise Deployment Guide.
`-Dweblogic.resourcepool.max_test_wait_secs=seconds`	The amount of time, in seconds, WebLogic Server waits before considering a connection test failed. By default, a server instance is assigned a value of 10 seconds. If set to zero, the server instance waits indefinitely.
`-Dweblogic.wsee.client.ssl.usejdk=true`	When set to true, switches from `WlsSSLAdapter` to `JdkSSLAdapter`. By default, WebLogic Server Web services use the `weblogic.wsee.connection.transport.https.WlsSSLAdapter` class for the SSL adapter. Setting the flag to true forces the use of `JdkSSLAdapter` from `weblogic.wsee.connection.transport.https.JdkSSLAdapter`. The `weblogic.wsee.connection.transport.https.HTTPSClientTransport` class that defines the `USE_JDK_SSL_PROPERTY` is used only in JAX-RPC. The property is not currently supported in JAX-WS.
`-Dweblogic.http.URIDecodeEncoding=charset-name`	The argument `charset-name` specifies the encoding used by the WebLogic Server Web container to decode the URI of an HTTP request or to encode the `Location` header in an HTTP response. The default value is `UTF-8`. See Determining the Encoding of an HTTP Request in Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server.
`-Dweblogic.utils.http.requestparams.useArrayMap= true`	When set to true in the server startup command, HTTP request parameters are stored using an ArrayMap. By default, HTTP request parameters are stored in a TreeMap.

Using the weblogic.Server Command Line to Start a Server Instance

The basic procedure to start a WebLogic Server instance is to run the setWLSEnv script to set the environment, change to the root directory of a domain, and enter the java weblogic.Server command.

Complete the following steps:

In a command shell, set up the required environment variables by running the following script:

WL_HOME\server\bin\setWLSEnv.cmd (on Windows)

WL_HOME/server/bin/setWLSEnv.sh (on UNIX)

where WL_HOME is the directory in which you installed the WebLogic Server software.
In the command shell, change to the root of the domain directory, usually ORACLE_HOME\user_projects\domains\DOMAIN_NAME. For example, change to the ORACLE_HOME\user_projects\domains\medrec directory.
To start an Administration Server, enter the following command:
```
java weblogic.Server 
```
Note:

The password you use must be a string of at least 8 case-sensitive characters. The space character is not supported. See Creating a WebLogic Domain in Creating WebLogic Domains Using the Configuration Wizard.
If the domain's Administration Server is already running, and if you have already defined a Managed Server in the config.xml file, you can start a Managed Server as follows:
```
java -Dweblogic.Name=managed-server-name 
-Dweblogic.management.server=url-for-Administration-Server 
weblogic.Server 
```
For example, if you create a Managed Server named MedRecManagedServer in the MedRec domain, you can enter the following command:
```
java -Dweblogic.Name=MedRecManagedServer 
-Dweblogic.management.server=localhost:7011 
weblogic.Server 
```

Note:

If you are using the demo certificates in a multi-server domain, Managed Server instances will fail to boot if you specify the fully-qualified DNS name of the Administration Server host machine, as in the argument url-for-Administration Server. See Limitation on CertGen Usage in Administering Security for Oracle WebLogic Server.

Using the weblogic.Server Command Line to Create a Domain

You can invoke the weblogic.Server class to create a domain that contains a single server instance. However, you cannot invoke the weblogic.Server class either to add Managed Server instances to a domain, or to modify an existing domain.

As described in Default Behavior, if weblogic.Server is unable to find a config.xml file, it offers to create the file. Any command option that you specify and that corresponds to an attribute that is persisted in the config.xml file will be persisted. For example, the -Dweblogic.Name and -Dweblogic.Domain options specify the name of a server configuration and the name of a domain. If weblogic.Server is unable to find a config.xml file, both of these values are persisted in config.xml. However, the -Dweblogic.system.BootIdentityFile option, which specifies a file that contains user credentials for starting a server instance, is not an attribute that the config.xml file persists.

To create and instantiate a simple example domain and server, do the following:

In a command shell, set up the required environment variables by running the following script:

WL_HOME\server\bin\setWLSEnv.cmd (on Windows)

WL_HOME/server/bin/setWLSEnv.sh (on UNIX)

where WL_HOME is the directory in which you installed the WebLogic Server software.
In the command shell, create an empty directory.

In the empty directory, enter the following command:

java -Dweblogic.Domain=SimpleDomain -Dweblogic.Name=SimpleServer
-Dweblogic.management.username=weblogic  -Dweblogic.management.password=password
-Dweblogic.ListenPort=7001 weblogic.Server

After you enter this command, WebLogic Server asks if you want to create a new config.xml file. If you enter y, it then instantiates a domain named SimpleDomain. The domain's Administration Server is configured as follows:

The name of the Administration Server is SimpleServer.
The domain's security realm defines one administrative user, weblogic, with a password of password.
For the listen address of the Administration Server, you can use localhost, the IP address of the host computer, or the DNS name of the host computer. See Configure listen addresses in the Oracle WebLogic Server Administration Console Online Help.
The Administration Server listens on port 7001.

Entering the weblogic.Server command as described in this section creates the following files:

config.xml
DefaultAuthenticatorInit.ldift, DefaultRoleMapperInit.ldift, and SerializedSystemIni.dat, which store basic security-related data.
boot.properties file, which contains the username and password in an encrypted format. This file enables you to bypass the prompt for username and password when you start the server. See Boot Identity Files in Administering Server Startup and Shutdown for Oracle WebLogic Server.
startWebLogic.cmd and startWebLogic.sh, that you can use to start subsequent instantiations of the server.

Note:

Invoking weblogic.Server in an empty directory results in implicit domain creation which uses the same configuration process as WLST offline and the Configuration Wizard and thus ensures that you always see uniform domains. As a result, implicitly creating a domain in an empty directory using weblogic.Server may take around 15 seconds.

Verifying Attribute Values That Are Set on the Command Line

The WebLogic Server Administration Console does not display values that you set on the command line because the startup options set attribute values for the server's local configuration MBean. To see the values that are in a server's local configuration MBean, use WLST instead as follows:

Complete the procedure described in Main Steps for Using WLST in Interactive or Script Mode in Understanding the WebLogic Scripting Tool.
```
>java weblogic.WLST
```
Start a WebLogic Server instance (see Starting and Stopping Servers in Administering Server Startup and Shutdown for Oracle WebLogic Server) and connect WLST to the server using the connect command. For detailed information about the connect command, see connect in the WLST Command Reference for WebLogic Server.
```
wls:/(offline)> connect('username','password','t3s://localhost:7002')
Connecting to weblogic server instance running at t3s://localhost:7002 as username weblogic ...

wls:/mydomain/serverConfig>
```
For example, to determine the multicast address that a cluster member is using, connect WLST to that server instance and enter the following commands:
```
wls:/mydomain/serverConfig> cd('Clusters/cluster_name')
wls:/mydomain/serverConfig/Clusters/mycluster> cmo.getMulticastAddress()

'239.192.0.0'
```
To determine the severity level of messages that the server instance prints to standard out, connect WLST to that server instance and enter the following commands:
```
wls:/mydomain/serverConfig> cd('Servers/server_name/Log/server_name')
wls:/mydomain/serverConfig/Servers/myserver/Log/myserver>cmo.getStdoutSeverity()

'Notice'
```

See Understanding the WebLogic Scripting Tooland Understanding WebLogic Server MBeans in Developing Custom Management Utilities Using JMX for Oracle WebLogic Server.