The WebLogic Deploy Tooling has a built-in logging framework based on
java.util.logging. Its logging configuration
is specified in
$WDT_HOME/etc/logging.properties. By default, the logging framework writes to both the console and
a log file.
By default, WDT tools write their log files to the
$WDT_HOME/logs directory and the log file name reflects the name of the tool.
For example, if you run the
validateModel tool then the log file will be
log files are overwritten each time you run a particular tool so the file contains only the logs from the last tool
$WDT_HOME/logs directory is not writable by the user running the tool, the logging framework will search for
a location to write the logs. The user must have write permission on the directory in order for it to be selected.
The search order is as follows:
user.dirJava system property) and create a
java.io.tmpdirJava system property) and create a
If none of these locations are writable, the logging framework prints an error message to
stderr and exits.
WDT tools output logging information to
stderr, as appropriate. By default, only
INFO level messages
are sent to
SEVERE messages are set to
stderr. In addition to regular log messages
generated as the tool runs, the tools will produce a summary at the end of tool execution that gives the user an
overview of the tool execution status. For example, the
validateModel tool execution with no warnings or errors will
produce output that looks similar to this:
Issue Log for validateModel version 2.0.0 running WebLogic version 188.8.131.52.0.210930 offline mode: Total: WARNING : 0 SEVERE : 0
As mentioned previously, WDT’s logging framework is based on
java.util.logging so all logging levels defined in
java.utiul.logging.Level class apply to WDT loggers. For a quick review of those levels, see the
WDT uses hierarchical loggers that align with the purpose of the code being executed. The root logger is named
Many loggers exist underneath the root logger; for example,
By default, the WDT
logging.properties file sets the logging level of the root and several important loggers. If the
level for a particular logger is not set, that logger will use the level of its parent logger. This delegation to the
parent logger is recursive up the hierarchy until it finds a level to use.
In WDT, the log file will collect log entries from all loggers based on the logger’s
level while the console output
is limited to
INFO and above only. Log entries written to the console will not display any exception stack traces
associated with a log entry. To see those, you must look at the log file. The WDT logging framework supports using the
wlsdeploy.debugToStdout Java system property to allow debug log messages (those logged at the
FINE level or below)
to appear in
stdout as long as the loggers to which the messages are logged are not filtering those log levels. For
example, doing the following will cause debug output to be written to the console:
export WLSDEPLOY_PROPERTIES=-Dwlsdeploy.debugToStdout=true weblogic-deploy/bin/prepareModel.sh ...
WDT uses several log handlers to handle logging output of data to various sources.
|Log Handler||Output Destination||Description|
||WDT tool log file||The standard
||WDT handler that writes
||WDT handler that writes
||WDT handler that writes the tool’s execution summary information to the console.|
By default, all four handlers are used and configured appropriately. The logging framework intentionally limits the
configurability of these handlers. Only the following
logging.properties file settings are allowed.
|Property||Value(s) Allowed||Behavior When Set|
||comma-separated list of handlers||The list of handlers to use (removing a handler from the list is the same as setting its
||No logging output will be saved in the log file.|
||No tool execution summary output will be written to the console.|
||Any number||Limits the number of memory-buffered
WLSDEPLOY_LOG_HANDLERS environment variable as an alternative to specifying the list of handlers in the
Any attempts to set other configuration for these log handlers will simply be discarded by the WDT logging framework at startup.