A Filter can be used to provide fine grain control over
what is logged, beyond the control provided by log levels.
This Handler publishes log records to System.err.
A Formatter provides support for formatting LogRecords.
A Handler object takes log messages from a Logger and
The Level class defines a set of standard logging levels that can be used to
control logging output.
A Logger object is used to log messages for a specific
system or application component.
The permission which the SecurityManager will check when code
that is running with a SecurityManager calls one of the logging
control methods (such as Logger.setLevel).
There is a single global LogManager object that is used to
maintain a set of shared state about Loggers and log services.
LogRecord objects are used to pass logging requests between
the logging framework and individual log Handlers.
Print a brief summary of the
LogRecord in a human readable
Stream based logging Handler.
Package java.util.logging Description
Provides the classes and interfaces of the CLDC platform's core logging facilities.
The central goal of the logging APIs is to support maintaining and servicing software at customer sites.
There are four main target uses of the logs:
- Problem diagnosis by end users and system administrators.
This consists of simple logging of common problems that can be fixed or tracked locally,
such as running out of resources, security failures, and simple configuration errors.
- Problem diagnosis by field service engineers.
The logging information used by field service engineers may be considerably
more complex and verbose than that required by system administrators.
Typically such information will require extra logging within particular subsystems.
- Problem diagnosis by the development organization.
When a problem occurs in the field, it may be necessary to return the captured
logging information to the original development team for diagnosis.
This logging information may be extremely detailed and fairly inscrutable.
Such information might include detailed tracing on the internal execution of particular subsystems.
- Problem diagnosis by developers.
The Logging APIs may also be used to help debug an application under development.
This may include logging information generated by the target application
as well as logging information generated by lower-level libraries.
Note however that while this use is perfectly reasonable,
the logging APIs are not intended to replace the normal debugging and profiling
tools that may already exist in the development environment.
The key elements of this package include:
- Logger: The main entity on which applications make logging calls.
A Logger object is used to log messages for a specific system or application component.
- LogRecord: Used to pass logging requests between the logging framework and individual log handlers.
- Handler: Exports LogRecord objects to a variety of destinations including memory,
output streams, consoles, files, and sockets.
Additional Handlers may be developed by third parties and delivered on top of the core platform.
- Level: Defines a set of standard logging levels that can be used to control logging output.
Programs can be configured to output logging for some levels while ignoring output for others.
- Filter: Provides fine-grained control over what gets logged,
beyond the control provided by log levels.
The logging APIs support a general-purpose filter mechanism that allows
application code to attach arbitrary filters to control logging output.
- Formatter: Provides support for formatting LogRecord objects.
This package includes only the SimpleFormatter for formatting log records in plain text.
As with Handlers, additional Formatters may be developed by third parties.
The Logging APIs offer dynamic configuration control.
Dynamic control allows for updates to the logging configuration within a currently running program.
The APIs also allow for logging to be enabled or disabled for different functional areas of the system.
In general, unless otherwise noted in the javadoc, methods and constructors will throw NullPointerException
if passed a null argument. The one broad exception to this rule is that the logging convenience methods
in the Logger class (the log, logp methods) will accept null values for all arguments
except for the initial Level argument (if any).
- 1.4, CLDC1.8