| author | ohair |
| Wed, 26 May 2010 20:28:04 -0700 | |
| changeset 5551 | 327690766109 |
| parent 5506 | 202f599c92aa |
| child 24196 | 61c9885d76e2 |
| permissions | -rw-r--r-- |
| 2 | 1 |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> |
2 |
<html> |
|
3 |
<head> |
|
4 |
<!-- |
|
| 5506 | 5 |
Copyright (c) 2001, 2006, Oracle and/or its affiliates. All rights reserved. |
| 2 | 6 |
DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. |
7 |
||
8 |
This code is free software; you can redistribute it and/or modify it |
|
9 |
under the terms of the GNU General Public License version 2 only, as |
|
| 5506 | 10 |
published by the Free Software Foundation. Oracle designates this |
| 2 | 11 |
particular file as subject to the "Classpath" exception as provided |
| 5506 | 12 |
by Oracle in the LICENSE file that accompanied this code. |
| 2 | 13 |
|
14 |
This code is distributed in the hope that it will be useful, but WITHOUT |
|
15 |
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or |
|
16 |
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License |
|
17 |
version 2 for more details (a copy is included in the LICENSE file that |
|
18 |
accompanied this code). |
|
19 |
||
20 |
You should have received a copy of the GNU General Public License version |
|
21 |
2 along with this work; if not, write to the Free Software Foundation, |
|
22 |
Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. |
|
23 |
||
|
5551
327690766109
6956202: Fix a few missed rebranding issues, please contact lines etc.
ohair
parents:
5506
diff
changeset
|
24 |
Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA |
|
327690766109
6956202: Fix a few missed rebranding issues, please contact lines etc.
ohair
parents:
5506
diff
changeset
|
25 |
or visit www.oracle.com if you need additional information or have any |
|
327690766109
6956202: Fix a few missed rebranding issues, please contact lines etc.
ohair
parents:
5506
diff
changeset
|
26 |
questions. |
| 2 | 27 |
--> |
28 |
||
29 |
</head> |
|
30 |
<body bgcolor="white"> |
|
31 |
<P> |
|
32 |
Provides the classes and interfaces of |
|
33 |
the Java<SUP><FONT SIZE="-2">TM</FONT></SUP> 2 |
|
34 |
platform's core logging facilities. |
|
35 |
The central goal of the logging APIs is to support maintaining and servicing |
|
36 |
software at customer sites. |
|
37 |
||
38 |
<P> |
|
39 |
There are four main target uses of the logs: |
|
40 |
</P> |
|
41 |
||
42 |
<OL> |
|
43 |
<LI> <I>Problem diagnosis by end users and system administrators</I>. |
|
44 |
This consists of simple logging of common problems that can be fixed |
|
45 |
or tracked locally, such as running out of resources, security failures, |
|
46 |
and simple configuration errors. |
|
47 |
||
48 |
<LI> <I>Problem diagnosis by field service engineers</I>. The logging information |
|
49 |
used by field service engineers may be considerably more complex and |
|
50 |
verbose than that required by system administrators. Typically such information |
|
51 |
will require extra logging within particular subsystems. |
|
52 |
||
53 |
<LI> <I>Problem diagnosis by the development organization</I>. |
|
54 |
When a problem occurs in the field, it may be necessary to return the captured logging |
|
55 |
information to the original development team for diagnosis. This logging |
|
56 |
information may be extremely detailed and fairly inscrutable. Such information might include |
|
57 |
detailed tracing on the internal execution of particular subsystems. |
|
58 |
||
59 |
<LI> <I>Problem diagnosis by developers</I>. The Logging APIs may also be |
|
60 |
used to help debug an application under development. This may |
|
61 |
include logging information generated by the target application |
|
62 |
as well as logging information generated by lower-level libraries. |
|
63 |
Note however that while this use is perfectly reasonable, |
|
64 |
the logging APIs are not intended to replace the normal debugging |
|
65 |
and profiling tools that may already exist in the development environment. |
|
66 |
</OL> |
|
67 |
||
68 |
</P> |
|
69 |
The key elements of this package include: |
|
70 |
<UL> |
|
71 |
<LI> <I>Logger</I>: The main entity on which applications make |
|
72 |
logging calls. A Logger object is used to log messages |
|
73 |
for a specific system or application |
|
74 |
component. |
|
75 |
<LI> <I>LogRecord</I>: Used to pass logging requests between the logging |
|
76 |
framework and individual log handlers. |
|
77 |
<LI> <I>Handler</I>: Exports LogRecord objects to a variety of destinations |
|
78 |
including memory, output streams, consoles, files, and sockets. |
|
79 |
A variety of Handler subclasses exist for this purpose. Additional Handlers |
|
80 |
may be developed by third parties and delivered on top of the core platform. |
|
81 |
<LI> <I>Level</I>: Defines a set of standard logging levels that can be used |
|
82 |
to control logging output. Programs can be configured to output logging |
|
83 |
for some levels while ignoring output for others. |
|
84 |
<LI> <I>Filter</I>: Provides fine-grained control over what gets logged, |
|
85 |
beyond the control provided by log levels. The logging APIs support a general-purpose |
|
86 |
filter mechanism that allows application code to attach arbitrary filters to |
|
87 |
control logging output. |
|
88 |
||
89 |
<LI> <I>Formatter</I>: Provides support for formatting LogRecord objects. This |
|
90 |
package includes two formatters, SimpleFormatter and |
|
91 |
XMLFormatter, for formatting log records in plain text |
|
92 |
or XML respectively. As with Handlers, additional Formatters |
|
93 |
may be developed by third parties. |
|
94 |
</UL> |
|
95 |
<P> |
|
96 |
The Logging APIs offer both static and dynamic configuration control. |
|
97 |
Static control enables field service staff to set up a particular configuration and then re-launch the |
|
98 |
application with the new logging settings. Dynamic control allows for updates to the |
|
99 |
logging configuration within a currently running program. The APIs also allow for logging to be |
|
100 |
enabled or disabled for different functional areas of the system. For example, |
|
101 |
a field service engineer might be interested in tracing all AWT events, but might have no interest in |
|
102 |
socket events or memory management. |
|
103 |
</P> |
|
104 |
||
105 |
<h2>Null Pointers</h2> |
|
106 |
<p> |
|
107 |
In general, unless otherwise noted in the javadoc, methods and |
|
108 |
constructors will throw NullPointerException if passed a null argument. |
|
109 |
The one broad exception to this rule is that the logging convenience |
|
110 |
methods in the Logger class (the config, entering, exiting, fine, finer, finest, |
|
111 |
log, logp, logrb, severe, throwing, and warning methods) |
|
112 |
will accept null values |
|
113 |
for all arguments except for the initial Level argument (if any). |
|
114 |
<p> |
|
115 |
<H2>Related Documentation</H2> |
|
116 |
<P> |
|
117 |
For an overview of control flow, |
|
118 |
please refer to the |
|
119 |
<a href="../../../../technotes/guides/logging/overview.html"> |
|
120 |
Java Logging Overview</a>. |
|
121 |
</P> |
|
122 |
||
123 |
<!-- Put @see and @since tags down here. --> |
|
124 |
||
125 |
@since 1.4 |
|
126 |
||
127 |
||
128 |
</body> |
|
129 |
</html> |
|
130 |
||
131 |
||
132 |
||
133 |
||
134 |