Books
in black and white
Main menu
Share a book About us Home
Books
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics
Ads

More Java Pitfalls Share Reactor - Daconta M,C.

Daconta M,C. More Java Pitfalls Share Reactor - Wiley publishing, 2003. - 476 p.
ISBN: 0-471-23751-5
Download (direct link): morejavapitfallssharereactor2003.pdf
Previous << 1 .. 17 18 19 20 21 22 < 23 > 24 25 26 27 28 29 .. 166 >> Next

39 m_log.fine("This is a test for fine");
40 m_log.info("This is a test for info");
41 m_log.warning("This is a warning test");
42 m_log.severe("This is a severe test");
43 }
44
45 /*
46 * A very simple example, where we will optionally
47 * pass in the level of granularity to our application
48 * /
49 public static void main(String[] args)
50 {
51 Level loglevel = Level.INFO;
52
53 if ( args.length !=0 )
54 {
55 if ( args[0].equals("ALL") )
56 {
57 loglevel = Level.ALL;
58 }
59 else if ( args[0].equals("FINE") )
60 {
61 loglevel = Level.FINE;
62 }
63 else if ( args[0].equals("FINEST") )
64 {
65 loglevel = Level.FINEST;
66 }
67 else if ( args[0].equals("WARNING") )
68 {
69 loglevel = Level.WARNING;
70 }
71 else if ( args[0].equals("SEVERE") )
72 {
73 loglevel = Level.SEVERE;
74 }
75
76 }
77 BadLoggerExample2 logex = new BadLoggerExample2(loglevel);
78 logex.test();
79 }
80 }
Listing 5.2 (continued)
50 Item 5
This time, we see the same output as before when we pass in the FINE argument, but a log file is generated, showing the XML output, shown in Listing 5.3! Now, standard error prints out the same seemingly incorrect thing as before, not showing the FINE test, and the FileHandler seems to write the correct output. What is going on? Why does the file output not match the output written to standard error?
<?xml version="1.0" encoding="windows-1252" standalone="no"?> <!DOCTYPE log SYSTEM "logger.dtd">
<log>
<record>
<date>2002-02-16T15:51:00</date>
<millis>1013892660502</millis>
<sequence>0</sequence>
<logger>org.pitfalls.BadLoggerExample2.logger</logger>
<level>FINE</level>
<class>org.pitfalls.logging.BadLoggerExample2</class>
<method>test</method>
<thread>10</thread>
<message>This is a test for fine</message>
</record>
<record>
<date>2002-02-16T15:51:00</date>
<millis>1013892660522</millis>
<sequence>1</sequence>
<level>INFO</level>
... <logger> <class>, <method> and <thread> elements same as above ...
<message>This is a test for info</message>
</record>
<record>
<date>2002-02-16T15:51:00</date>
<millis>1013892660612</millis>
<sequence>2</sequence>
<level>WARNING</level>
<message>This is a warning test</message>
</record>
<record>
<date>2002-02-16T15:51:00</date>
<millis>1013892660622</millis>
<sequence>3</sequence>
<level>SEVERE</level>
<message>This is a severe test</message>
</record>
</log>
Listing 5.3 XML-formatted output from FileHandler
Avoiding Granularity Pitfalls in java.util.logging 51
Parent Logger Log Messages higher than and equal to Handler
Granularity A Granularity A are sent to Handlers Granularity C
Log Messages higher than and equal to Granularity B are sent to Logger Parent
Log Messages higher than and equal to Granularity C are logged
Log Messages higher than and equal to
Granularity B are sent to Handlers
Log Messages higher than and equal to Granularity D are logged
Level.SEVERE /
Level.WARNING
Level.INFO
Level.CONFIG RI 5 D N RAN G
Level.FINE
Level.FINER
Level.FINEST

Level.ALL
Figure 5.2 Logger/handler relationship diagram.
This behavior is quite strange. What happened? There are actually three things that we need to understand in order to understand this strange behavior:
Default Configurations of Loggers and Handlers. Loggers and handlers have default configurations, read from a preference file in your JRE's lib directory. A key thing to understand is that granularities may be set for each, using the setLevel() method.
Inheritance of Loggers. Another key thing to understand about the logging API is that each logger has a parent, and all data sent to a logger will go to its parent as well. The top parent is always the Root Logger, and you can create an inheritance tree descending from the Root Logger. In our initial example in Listing 5.1, we did not set a handler, but we still had output. Why? The reason is the Root Logger had a ConsoleHandler, whose default content level is Level.INFO. You can disable sending log messages to your parent's handler by calling the setUseParentHandlers(false) on the Logger class.
The Relationship between Handlers and Loggers. As we mentioned before, there are default levels of handlers. By default, all ConsoleHandlers log at the Level.INFO level, and all FileHandlers log at the Level.ALL level. The logger itself can set its level, and you can also set the level of the handlers. The key is that the level of the handler can never show a lower level of granularity than the logger itself. For example, if the logger's level is set to Level.INFO, the attached handlers will only see Level.INFO levels and above (from our diagram in Figure 5.1). In our example in Listing 5.2, we set our logger level to Level.FINE, and because the FileHandler's level was the default level (Level.ALL), it only saw what the logger was able to pass through (FINE and below).
Previous << 1 .. 17 18 19 20 21 22 < 23 > 24 25 26 27 28 29 .. 166 >> Next