Search your topic in Java2share
Home > FAQs
eXTReMe Tracker


Weblogic Application Server FAQs

41.How will you Enable and disable the domain configuration lock?
The Administration Console Change Center provides a way to lock a domain configuration so you can make changes to the configuration while preventing other accounts from making changes during your edit session.

The domain configuration locking feature is always enabled in production domains. It can be enabled or disabled in development domains. It is disabled by default when you create a new development domain.

To enable or disable the domain configuration locking feature in a development domain:

  • In the banner toolbar region at the top of the right pane of the Console, click Preferences.
  • Click User Preferences.
  • Select or clear Automatically Acquire Lock and Activate Changes to enable or disable the feature.
  • Click Save.
  • After you finish

When you enable domain configuration locking, you must use the Change Center to lock and edit for the domain configuration.
42.What are Dynamic and Non-Dynamic Changes in the Weblogic Console? what is the difference?
Some changes you make in the Administration Console take place immediately when you activate them. Other changes require you to restart the server or module affected by the change. These latter changes are called non-dynamic changes. Non-dynamic changes are indicated in the Administration Console with this warning icon,.

Changes to dynamic configuration attributes become available once they are activated, without restarting the affected server or system restart. These changes are made available to the server and run-time hierarchies once they are activated. Changes to non-dynamic configuration attributes require that the affected servers or system resources be restarted before they become effective.

If a change is made to a non-dynamic configuration setting, no changes to dynamic configuration settings will take effect until after restart. This is to assure that a batch of updates having a combination of dynamic and non-dynamic attribute edits will not be partially activated.

Note that WebLogic Server’s change management process applies to changes in domain and server configuration data, not to security or application data.
43.What is the information is going to store in the “security” folder of the Domain directory contents?
This directory holds the security-related files that are the same for every WebLogic Server instance in the domain:

  • SerializedSystemIni.dat

This directory also holds security-related files that are only needed by the domain’s Administration Server:

  • DefaultAuthorizerInit.ldift
  • DefaultAuthenticatorInit.ldift
  • DefaultRoleMapperInit.ldift

44.What is the use of SerializedSystemIni.dat file in Weblogic?
It is important to protect passwords that are used to access resources in a WebLogic Server domain. In the past, usernames and passwords were stored in clear text in a WebLogic security realm. Now all the passwords in a WebLogic Server domain are hashed. The SerializedSystemIni.dat file contains the hashes for the passwords. It is associated with a specific WebLogic Server domain so it cannot be moved from domain to domain.

If the SerializedSystemIni.dat file is destroyed or corrupted, you must reconfigure the WebLogic Server domain. Therefore, you should take the following precautions:

Make a backup copy of the SerializedSystemIni.dat file and put it in a safe location.
Set permissions on the SerializedSystemIni.dat file such that the system administrator of a WebLogic Server deployment has write and read privileges and no other users have any privileges.

45.Explain about Domain Directory Contents?
By default, WebLogic Server creates domain directories under the BEA_HOME/user_projects/domains directory. This section describes the contents of the domain directory and its subfolders. In this section, domain-name, deployment-name, and server-name represent names that you define when you create a domain.
Individual applications in a domain might create additional files and directories in the domain directory.
If you have not yet created a domain, you can see an example of an existing domain directory by looking in WL_HOME/examples/domains/wl_server where WL_HOME is the directory in which you installed WebLogic Server.
Domain-name
The name of this directory is the name of the domain.
autodeploy
This directory provides a quick way to deploy applications in a development server. When the WebLogic Server instance is running in development mode, it automatically deploys any applications or modules that you place in this directory.

The files you place in this directory can be Java EE applications, such as:

  • An EAR file
  • A WAR, EJB JAR, RAR, or CAR archived module
  • An exploded archive directory for either an application or a module

 

Bin
This directory contains scripts that are used in the process of starting and stopping the Administration Server and the Managed Servers in the domain. These scripts are generally provided as .sh files for UNIX and .cmd files for Windows. The bin directory can optionally contain other scripts of domain-wide interest, such as scripts to start and stop database management systems, full-text search engine processes, etc. 

Config
This directory contains the current configuration and deployment state of the domain. The central domain configuration file, config.xml, resides in this directory.

Config/configCache
Contains data that is used to optimize performance when validating changes in the domain’s configuration documents. This data is internal to WebLogic Server and does not need to be backed up.

Config/diagnostics
This directory contains system modules for instrumentation in the WebLogic Diagnostic Framework.

Config/jdbc
This directory contains system modules for JDBC: global JDBC modules that can be configured directly from JMX (as opposed to JSR-88).

Config/jms
This directory contains system modules for JMS: global JMS modules that can be configured directly from JMX (as opposed to JSR-88).

Config/lib
This directory is not used in the current release of WebLogic Server.

Config/nodemanager
This directory holds configuration information for connection to the Node Manager.

Config/security
This directory contains system modules for the security framework. It contains one security provider configuration extension for each kind of security provider in the domain’s current realm.

Config/startup
This directory contains system modules that contain startup plans. Startup plans are used to generate shell scripts that can be used as part of server startup.

ConfigArchive
This directory contains a set of JAR files that save the domain’s configuration state. Just before pending changes to the configuration are activated, the domain’s existing configuration state, consisting of the config.xml file and the other related configuration files, is saved in a versioned JAR file with a name like config.jar#1, config.jar#2, etc.

The maximum number of versioned JAR files to be kept is specified by the archiveConfigurationCount attribute of DomainMBean. Once this maximum number is reached, the oldest conversion archive is deleted before a new one is created.

Console-ext
This directory contains extensions to the Administration Console, which enable you to add content to the WebLogic Server Administration Console, replace content, and change the logos, styles and colors without modifying the files that are installed with WebLogic Server. For example, you can add content that provides custom monitoring and management facilities for your applications. See Extending the Administration Console.

Init-info
This directory contains files used for WebLogic domain provisioning. You should not modify any files in this directory.

Lib
Any JAR files you put in this directory are added to the system classpath of each server instance in the domain when the server’s Java virtual machine starts.

Pending
This directory contains domain configuration files representing configuration changes that have been requested, but not yet activated. Once the configuration changes have been activated, the configuration files are deleted from this directory. 

Security
This directory holds those security-related files that are the same for every WebLogic Server instance in the domain:

  • SerializedSystemIni.dat

This directory also holds security-related files that are only needed by the domain’s Administration Server:

  • DefaultAuthorizerInit.ldift
  • DefaultAuthenticatorInit.ldift
  • DefaultRoleMapperInit.ldift

 

Servers
This directory contains one subdirectory for each WebLogic Server instance in the domain. The subdirectories contain data that is specific to each server instance.

Servers/server-name
This directory is the server directory for the WebLogic Server instance with the same name as the directory.

Servers/server-name/bin
This directory holds executable or shell files that can be or must be different for each server. The server environment script (setServerEnv.sh or setServerEnv.cmd) is an example of a file that resides here because it can differ from one WebLogic Server instance to the next, for example, depending on whether the server instance has its own startup plan.

Servers/server-name/cache
This directory holds directories and files that contain cached data. By “cached” here we mean that the data is a copy, possibly in a processed form (compiled, translated, or reformatted), of other data.

Servers/server-name/cache/EJBCompilerCache
This directory is a cache for compiled EJBs.

Servers/server-name/data
This directory holds files that maintain persistent per-server state used to run the WebLogic Server instance, other than security state, as opposed to temporary, cached or historical information. Files in this directory are important data that must be retained as the WebLogic Server instance is brought up, is brought down, crashes, restarts, or is upgraded to a new version.

Servers/server-name/data/ldap
This directory holds the embedded LDAP database. The run-time security state for the WebLogic Server instance is persisted in this directory.

Servers/server-name/data/store
This directory holds WebLogic persistent stores. For each persistent store, there is a subdirectory that holds the files that represent the persistent store. The name of the subdirectory is the name of the persistent store. By convention there is one store named default.

Servers/server-name/logs
This directory holds logs and diagnostic information. This information is historical in nature. It is not crucial to the operation of the server, and can be deleted (while the WebLogic Server instance is down, at least) without affecting proper operation. However, the information can be quite useful for debugging or auditing purposes and should not be deleted without good reason.

Servers/server-name/logs/diagnostic_images
This directory holds information created by the Server Image Capture component of the WebLogic Diagnostic Framework.

Servers/server-name/logs/jmsServers
This directory contains one subdirectory for each JMS server in the WebLogic Server instance. Each such subdirectory contains the logs for that JMS server. The name of the subdirectory is the name of the JMS server.

Servers/server-name/logs/connector
This directory is the default base directory for connector module (JCA ResourceAdapter) logs.

Servers/server-name/security
This directory holds security-related files that can be or must be different for each WebLogic Server instance. The file boot.properties is an example of a file that resides here because it can differ from one server to the next. This directory also maintains files related to SSL keys.

Servers/server-name/tmp
This directory holds temporary directories and files that are created while a server instance is running. For example, a JMS paging directory is automatically created here unless another location is specified. Files in this directory must be left alone while the server is running, but may be freely deleted when the server instance is shut down.

Tmp
This directory stores temporary files used in the change management process. You should not modify any files in this directory.

user_staged_config
By default, configuration information is automatically copied from the Administration Server to each Managed Server. If instead you prefer to stage configuration changes manually, you can use this directory as an alternative to the config directory.

46.How many ways you can change the configuration changes?
The change management features of WLS:

    • Enable you to distribute configuration changes throughout a domain securely, consistently, and predictably
    • Are the same, regardless of whether you are using:
      • The WLS Administration Console
      • The WebLogic Scripting Tool (WLST)
      • The Java Management Extension (JMX) APIs

47.What is the user of WLST in Weblogic?

    • The WLS command-line tools are useful:
      • For automating common administration activities
      • As an alternative to the Administration Console
      • When graphical tools are not supported
    • WLST provides a command-line interface for:
      • Creating new WLS domains
      • Retrieving and updating WLS domain configurations
      • Deploying applications
      • Obtaining run-time server statistics

48.How many WLST modules are there? Explain?

    • Online mode:
      • Connected to a running server
      • Access to all WLS configuration and run-time attributes
      • Create and activate change sessions similar to the WLS console
    • Offline mode:
      • Domain not running
      • Access to only persisted domain configuration (config.xml)
      • Create or update domains similar to using the Configuration Wizard

49.What is the Node Manager (NM)? Explain briefly?
Node Manager (NM):

    • Starts and stops Managed Servers remotely: server, domain, and cluster
    • Available as either a Java-based or (for UNIX or Linux) a script-based process
    • Monitors and acts on server health
    • Runs on the same computers as the Managed Servers
    • Can be run automatically in the background, as a Windows service or a UNIX daemon

50.How many versions of Node Managers are available?

    • There are two versions of Node Manager:
      • Java-based Node Manager
      • Script-based Node Manager
    • Java-based Node Manager runs within a Java Virtual Machine (JVM) process.
    • Script-based Node Manager (used only for UNIX and Linux systems) does not have as much security, but provides the ability to remotely manage servers over a network using Secure Shell (SSH).