51.How Node Manager will work with the Weblogic Server? How will you configure Node Manager in WLS?

Node Manager must run on each computer that hosts the WLS instances that you want to control with Node Manager.
You should configure each computer as a machine in Oracle WebLogic Server, and assign each server instance, which is to be controlled by Node Manager, to the machine that the server instance runs on.
Node Manager should run as an operating system service, so that it automatically restarts upon system failure or reboot.

52.What is the Node Manager Default Behavior?

After WebLogic Server is installed, Node Manager is “ready-to-run” if Node Manager and Administration Server are on the same machine.
By default, the following behaviors are configured:

The Administration Console can use Node Manager to start the Managed Servers.
Node Manager monitors the Managed Servers that it started.
The automatic restart of Managed Servers is enabled.

53.To start Node Manager at system start up time, what we have to do?
We have to configure Node Manager as a Operating System Service.

It is recommended that you run Node Manager (NM) as:

A Windows service on Windows platforms and
A daemon on UNIX platforms

Running NM during system startup allows it to restart automatically when the system is rebooted.
Node Manager can be configured to start at boot time, as either of these:

A Windows service
A UNIX daemon

54.How will you configure Node Manager as Windows Service?

Edit installNodeMgrSvc.cmd to specify Node Manager’s listen address and listen port.
Run installNodeMgrSvc.cmd to reinstall Node Manager as a service, listening on the updated address and port.
Delete the Node Manager Service using uninstallNodeMgrSvc.cmd.

55.Explain about Weblogic server Log Message Format?
When a WebLogic Server instance writes a message to the server log file, the first line of each message begins with #### followed by the message attributes. Each attribute is contained between angle brackets.

Here is an example of a message in the server log file:
####<Jan 05, 2010 10:46:51 AM EST> <Notice> <WebLogicServer> <MyComputer> <examplesServer> <main> <<WLS Kernel>> <> <null> <1080575211904> <BEA-000360> <Server started in RUNNING mode> In this example, the message attributes are: Locale-formatted Timestamp, Severity, Subsystem, Machine Name, Server Name, Thread ID, User ID, Transaction ID, Diagnostic Context ID, Raw Time Value, Message ID, and Message Text.
If a message is not logged within the context of a transaction, the angle brackets for Transaction ID are present even though no Transaction ID is present.
If the message includes a stack trace, the stack trace is included in the message text.
WebLogic Server uses the host computer’s default character encoding for the messages it writes.
56.What is the Log Message Formant of Output to Standard Out and Standard Error?
When a WebLogic Server instance writes a message to standard out, the output does not include the #### prefix and does not include the Server Name, Machine Name, Thread ID, User ID, Transaction ID, Diagnostic Context ID, and Raw Time Value fields.

Here is an example of how the message from the previous section would be printed to standard out:

<jan 01, 2010 10:51:10 AM EST> <Notice> <WebLogicServer> <BEA-000360> <Server started in RUNNING mode>In this example, the message attributes are: Locale-formatted Timestamp, Severity, Subsystem, Message ID, and Message Text.
57.How many log Message Severity levels are there in Weblogic? Explain?
The severity attribute of a WebLogic Server log message indicates the potential impact of the event or condition that the message reports.

Severity	Meaning
TRACE	Used for messages from the Diagnostic Action Library. Upon enabling diagnostic instrumentation of server and application classes, TRACE messages follow the request path of a method.
INFO	Used for reporting normal operations; a low-level informational message.
NOTICE	An informational message with a higher level of importance.
WARNING	A suspicious operation or configuration has occurred but it might not affect normal operation.
ERROR	A user error has occurred. The system or application can handle the error with no interruption and limited degradation of service.
CRITICAL	A system or service error has occurred. The system can recover but there might be a momentary loss or permanent degradation of service.
ALERT	A particular service is in an unusable state while other parts of the system continue to function. Automatic recovery is not possible; the immediate attention of the administrator is needed to resolve the problem.
EMERGENCY	The server is in an unusable state. This severity indicates a severe system failure or panic.
DEBUG	A debug message was generated.

58.What is the default log Message Severity levels in Weblogic?
WebLogic Server subsystems generate many messages of lower severity and fewer messages of higher severity. For example, under normal circumstances, they generate many INFO messages and no EMERGENCY messages.
59.What is the Log Message Severity Level sequence from lowest to highest impact?
A log level object can specify any of the following values, from lowest to highest impact:
TRACE, DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY
60.How will you specify the logging implementation in Weblogic?
We will specify the logging implementation using "Java Logging API" or "Log4j" in Weblogic.
About Log4j
Log4j has three main components: loggers, appenders, and layouts. The following sections provide a brief introduction to Log4j.

Loggers
Log4j defines a Logger class. An application can create multiple loggers, each with a unique name. In a typical usage of Log4j, an application creates a Logger instance for each application class that will emit log messages. Loggers exist in a namespace hierarchy and inherit behavior from their ancestors in the hierarchy.

Appenders
Log4j defines appenders (handlers) to represent destinations for logging output. Multiple appenders can be defined. For example, an application might define an appender that sends log messages to standard out, and another appender that writes log messages to a file. Individual loggers might be configured to write to zero or more appenders. One example usage would be to send all logging messages (all levels) to a log file, but only ERROR level messages to standard out.

Layouts
Log4j defines layouts to control the format of log messages. Each layout specifies a particular message format. A specific layout is associated with each appender. This lets you specify a different log message format for standard out than for file output, for example.

Java Logging API
WebLogic logging services provide the Commons LogFactory and Log interface implementations that direct requests to the underlying logging implementation being used by WebLogic logging services.

To use Commons Logging, put the WebLogic-specific Commons classes, $BEA_HOME/modules/com.bea.core.weblogic.commons.logging_1.3.0.0.jar, together with the commons-logging.jar file in one of the following locations:

APP-INF/LIB or WEB-INF/LIB directory
DOMAIN_NAME/LIB directory
Server CLASSPATH
Note: WebLogic Server does not provide a Commons logging version in its distribution.