|
And you can write to any and all of these different logs with a
single call to a CompositeLogger , which contains any number of other
custom loggers. There is also an InsistentLogger which
you can use to wrap any other logger. This logger will continually try to relog
to its wrapped logger whenever the wrapped logger fails to properly log. (e.g.
You could wrap a SerialSocketLogger with an InsistentLogger. Then, if
the end receiving logs over a socket happens to go down temporarily, the log
entries will still get logged once the receiver is back online.)
The framework has hooks for you to filter entries that get logged.
For example, you might want one log to write all information that it receives,
but you could reserve a support page log to handle only entries that are severe
enough to warrant a page. Also, you can filter entries based on the type of
entry, or what the framework refers to as a "category," which can be anything
that you define, or simply be a String. You could have a "database" category,
for instance. A logger could exist that handles only these database log
entries.
There are also hooks in the framework for formatting log entries any
way you need. You can simply subclass one of the provided formatting classes
and instruct the logger to use your new formatter.
Your application doesn't need to distinguish between the various logs
that it might have. Once the logs are setup, your application can log
everything it needs to one central logger, knowing that there may be any number
of other logs being automatically notified with proper filtering and
formatting.
Click the diagram for a larger
view of the class hierarchy
|