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 the Node Manager.
This section describes the following:
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 Managing Server Startup and Shutdown.
For information about using the Node Manager to start an instance of WebLogic Server, see " Using Node Manager to Control Servers” in Managing Server Startup and Shutdown.
This section describes the environment that you must set up before you can start a server instance. Then it describes the syntax for invoking weblogic.Server
.
To set up your environment for the weblogic.Server
command:
CLASSPATH
environment variable, as described in
Modifying the Classpath.PATH
environment variable. You can use any JVM that is listed in the Supported Configurations page at
http://e-docs.bea.com/platform/suppconfigs/index.html.
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.
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 PointBase 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:
commEnv.cmd/sh
script in WL_HOME
/common/bin
and prepend your JAR file to the WEBLOGIC_CLASSPATH
environment variable.setDomainEnv.cmd/sh
script in that domain’s bin
directory, and prepend the JAR file to the PRE_CLASSPATH
environment variable. If you use the trial version of PointBase, an all-Java database management system, include the following files on the classpath:
WL_HOME
/common/eval/pointbase/lib/pbembedded51.jar and pbclient51.jar
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
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 (:).
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.
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:
domain_name
/config
directory for a file named config.xml
.config.xml
exists in the domain_name
/config
directory, WebLogic Server does the following:myserver
. If it finds such a server configuration, it starts the myserver
instance. myserver
, WebLogic Server exits the weblogic.Server
process and generates an error message.config.xml
file in the current directory, WebLogic Server prompts you to create one. If you respond y
, WebLogic Server does the following: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. For more information, see “ Configuration File Archiving” in Understanding Domain Configuration.
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. For more information, see "
Boot Identity Files" in Managing Server Startup and Shutdown.
bin/startWebLogic.cmd
and bin/startWebLogic.sh
, that 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.
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 Administration Console or WebLogic Scripting Tool (WLST) to modify the config.xml
file. See "
Creating and Configuring WebLogic Domains Using WLST Offline" in 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.
The following table 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 the Supported Configurations page at http://e-docs.bea.com/platform/suppconfigs/index.html.
The minimum content for this option is described under Modifying the Classpath.
|
|
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 the Supported Configurations page at
http://e-docs.bea.com/platform/suppconfigs/index.html.
|
|
To display special characters on Linux browsers, set the JVM’s
file.encoding system property to ISO8859_1 . For example, java -Dfile.encoding=ISO8859_1 weblogic.Server .
For a complete listing, see Sun’s “
Supported Encodings” page for J2SE 1.4.2.
|
All server instances must have access to and configuration data. The following table provides options for indicating the location of this data.
Specifies the server’s root directory. See “A Server’s Root Directory” in Understanding Domain Configuration.
|
|||
Specifies a configuration file for your domain. The
file_name value must see a valid XML file that conforms to the schema as defined in the "
BEA WebLogic Server Configuration Reference".
The XML file must exist in the Administration Server’s root directory, which is either the current directory or the directory that you specify with
-Dweblogic.RootDirectory .
|
|||
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 at the following pathname:
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 4-3.
The 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.
The following example starts an Administration Server instance named SimpleServer. In the example, the config.xml
file has been renamed to SimpleDomain.xml
and it is located in a directory named c:\my_domains\SimpleDomain
. The command itself is issued from the D:\
directory after running WL_HOME
\server\bin\setWLSEnv.cmd
(where WL_HOME
is the directory in which you installed WebLogic Server):
D:\> java -Dweblogic.Name=SimpleServer -Dweblogic.ConfigFile=SimpleDomain.xml -Dweblogic.RootDirectory=c:\my_domains\SimpleDomain weblogic.Server
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
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.
Caution: | 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 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 4-1.)
The following options temporarily override a server’s configuration:
The following table describes the options for configuring how servers communicate.
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.
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.
For more information on configuring a connection to the Administration Server, see "
Configuring a Connection to the Administration Server" in Managing Server Startup and Shutdown.
|
|||||
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 the Administration Console or WLST to modify the config.xml file.
For more information, see "
Configure listen addresses" in the Administration Console Online Help and "
Creating and Configuring WebLogic Domains Using WLST Offline" in WebLogic Scripting Tool.
|
|||||
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 the Administration Console or WLST to modify the config.xml file.
For more information, see "
Configure listen ports" in the Administration Console Online Help and "
Creating and Configuring WebLogic Domains Using WLST Offline" in WebLogic Scripting Tool.
|
|||||
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 the Administration Console or WLST to modify the config.xml file.
For more information, see "
Configure listen ports" in the Administration Console Online Help and "
Creating and Configuring WebLogic Domains Using WLST Offline" in WebLogic Scripting Tool.
|
|||||
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.
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 . For more information, see "
Managed Servers and Re-started Administration Server" in Managing Server Startup and Shutdown.
|
The 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.
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.
The following table describes the options for configuring a server to communicate using Secure Sockets Layer (SSL).
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.
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 Administration Console or WLST to modify the config.xml file.
For more information, see "
Using Hostname Verification" in Securing WebLogic Server.
|
|||
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.
|
|||
If you configure a server instance to use the SSL features that were available before WebLogic Server 8.1, you can use this argument to specify the certificate authorities that the server or client trusts. The
path value must be a relative or qualified name to the Sun JKS keystore file (contains a repository of keys and certificates).
If a server instance is using the SSL features that were available before 8.1, and if you do not specify this argument, the WebLogic Server or client trusts all of the certificates that are specified in
JAVA_HOME \jre\lib\security .
BEA recommends that you do not use the demonstration certificate authorities in any type of production deployment.
For more information, see "
Configuring SSL" in the Securing Weblogic Server.
|
The 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.
To set additional SSL attributes from the startup command, do the following:
Each attribute that SSLMBean
and ServerMBean
expose as a setter method can be set by a startup option.
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.
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:
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
The 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.
The following table describes the options for configuring general security parameters.
The username must belong to a role that has permission to start a server. For information on roles and permissions, see "Users, Groups, an Security Roles" in Securing WebLogic Resources.
This option prevents a server instance from using any boot identity file and overrides other startup options that cause a server to use boot identity files. For more information, see "
Boot Identity Files" in Managing Server Startup and Shutdown.
|
|||
This option prevents a server instance from using any boot identity file and overrides other startup options that cause a server to use boot identity files. For more information, see "
Boot Identity Files" in Managing Server Startup and Shutdown.
|
|||
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 . For more information, see "Specifying User Credentials When Starting a Server with the Node Manager" in Managing Server Startup and Shutdown.
BEA 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.
For more information, see "
Boot Identity Files" in Managing Server Startup and Shutdown.
|
|||
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
weblogic.Admin SHUTDOWN and FORCESHUTDOWN commands use the boot.properties file in the server’s root directory.
|
|||
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.
For more information, see “
Users, Groups, an Security Roles” in Securing WebLogic Resources.
|
|||
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.
Using
-Djava.security.policy== filename (note the double equal sign (== )) causes the policy file to override any default security policy. This causes WebLogic Server to ignore any policy files that are used for servlet and EJB authorization when JACC is enabled. A single equal sign (= ) causes the policy file to be appended to an existing security policy.
For more information, see “
Using the Java Security Manager to Protect WebLogic Resources” in the Programming WebLogic Security guide.
|
|||
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 SecurityGeneral page in the Administration Console.
By default, the
MBeanHome API allows access to MBeans only for WebLogic users who are in one of the default security roles. For more information, see "
Users, Groups, an Security Roles" in Securing WebLogic Resources.
|
|||
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.
|
|||
Defining these five system properties is required to enable the use of the JACC provider in the security realm. When these providers are in use, the 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. JACC authorization requires the use of J2SE security and therefore requires that WebLogic Server be booted with a Java EE security manager and a policy file (specified by the server startup properties,
java.security.manager and java.security.policy ). For more information, see “
Using the Java Security Manager to Protect WebLogic Resources” in Programming WebLogic Security.
|
|||
The 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.
The following table describes options for configuring a server instance’s message output.
Redirects the server and JVM’s standard error stream to a file. You can specify a pathname that is fully qualified or relative to the WebLogic Server root directory.
For more information, see "
Redirecting JVM output" in Configuring Log Files and Filtering Log Messages.
|
|
The 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.
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:
Each attribute that the LogMBean
exposes as a setter method can be set by a startup option.
-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:
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
The 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.
The following table describes options for configuring additional attributes of a server instance.
A
true value prevents a WebLogic Server from automatically deploying and updating applications that are in the domain_name /autodeploy directory.
To enable production mode, you can use WLST to set
DomainMBean.isProductionModeEnabled to true , or use the Administration Console. See "
Change to production mode" in the Administration Console Online Help.
|
|||||
To use this startup argument, the domain must be configured to use the domain-wide administration port. For information about administration ports, see “ Administration Port and Administrative Channel” in Configuring WebLogic Server Environments and " Configure the domain-wide administration port" in the Administration Console Online Help. |
|||||
See “
Using the WebLogic JSP Compiler” in Developing Web Applications, Servlets, and JSPs for WebLogic Server.
|
|||||
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 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.
The following table describes options for configuring additional attributes of a cluster.
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 .
|
A simple way to start a server instance is as follows:
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.
BEA_HOME
\user_projects\domains\
DOMAIN_NAME
. For example, change to the WL_HOME
\samples\domains\medrec
directory.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. For more information, see “ Configure an Administrator Username and Password” in Creating WebLogic Domains Using the Configuration Wizard. |
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
You can use weblogic.Server
to create a domain that contains a single server instance. You cannot use weblogic.Server
to add Managed Server instances to a domain, nor can you use weblogic.Server
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:
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.
java -Dweblogic.Domain=SimpleDomain -Dweblogic.Name=SimpleServer
-Dweblogic.management.username=weblogic -Dweblogic.management.password=weblogic -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:
weblogic
, with a password of weblogic
.localhost
, the IP address of the host computer, or the DNS name of the host computer. For more information about setting the listen address, see "
Configure the listen addresses" in the Administration Console Online Help.
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. For more information, see "
Boot Identity Files" in Managing Server Startup and Shutdown.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. |
The 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 as follows:
connect
command. For detailed information about the connect
command, see “
connect” in the WLST Command and Variable Reference.
wls:/(offline)>
connect('username','password','t3s://localhost:7002')
Connecting to weblogic server instance running at t3s://localhost:7002 as username weblogic ...
wls:/mydomain/serverConfig>
cd('Clusters/cluster_name')
wls:/mydomain/serverConfig/Clusters/mycluster>
cmo.getMulticastAddress()
wls:/mydomain/serverConfig>
cd('Servers/server_name/Log/server_name')
wls:/mydomain/serverConfig/Servers/myserver/Log/myserver>
cmo.getStdoutSeverity()
For more information on using WLST, see WebLogic Scripting Tool. For more information about configuration MBeans, see " Understanding WebLogic Server MBeans" in Developing Custom Management Utilities with JMX.