This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 31228 - Discrepancy between ErrorManager logging levels
Summary: Discrepancy between ErrorManager logging levels
Status: RESOLVED FIXED
Alias: None
Product: obsolete
Classification: Unclassified
Component: sim (show other bugs)
Version: -S1S-
Hardware: PC Linux
: P2 blocker (vote)
Assignee: issues@obsolete
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2003-02-19 17:07 UTC by _ pkuzel
Modified: 2003-02-24 19:54 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description _ pkuzel 2003-02-19 17:07:39 UTC
Following test case, prints out "INFORMATIONAL is
loggable" but does not log next message. IFAIK
EM.isLoggable() should return false for Nevada.

It's incosistent if isLoggable returns true
permitting a computation of time consuming log
messages and then nothing is logged down.

import org.openide.ErrorManager;


public class TestLogger {

    /** Creates a new instance of TestLogger */
    public TestLogger() {
    }

    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) {
        ErrorManager e =
ErrorManager.getDefault().getInstance("org.netbeans.modules.xml.core");
        if
(e.isLoggable(ErrorManager.INFORMATIONAL)) {
            System.err.println("INFORMATIONAL is
loggable");
            e.log(ErrorManager.INFORMATIONAL,
"Message logged at informational level.");
        }
    }

}
Comment 1 _ pkuzel 2003-02-19 17:08:33 UTC
isLoggable() is used to guard time consuming sections.
Comment 2 Jesse Glick 2003-02-19 18:36:10 UTC
I will investigate. Note that the bug does *not* exist in NB as far as
I can tell.
Comment 3 Jesse Glick 2003-02-20 02:04:48 UTC
org.netbeans.modules.sim.bugsubmitter.ui.BugsubmitterErrorManager is
at fault. It fails to override methods in ErrorManager such as
isLoggable and isNotifiable. getInstance is also overridden
incorrectly, meaning that per-module diagnostic logging will probably
not work in Nevada as is.

Suggest as a starting point that
core/test/unit/src/org/netbeans/core/NbErrorManagerTest.java be
adapted to BugsubmitterErrorManager (made into part of a test suite
for the sim/bugsubmitter module).
Comment 4 Terry Heatlie 2003-02-20 07:02:04 UTC
I've temporarily removed our META-INF file which registers our
ErrorManager and de-registers the NB one.  This should restore
the behaviour of Nevada to that of NetBeans.  We will adopt
Jesse's suggestion of adapting the core test case, and will 
not re-insert our registration until our EM passes said test.

Many apologies for the problem...
Comment 5 Terry Heatlie 2003-02-21 01:12:43 UTC
isLoggable() and isNotifiable() have been added.
The unit test has been updated, and is now essentially
a copy of the core unit test.

6 of 7 tests now pass.  The last one will not pass until
the implementation of getInstance() is fixed.  I intend to
work on that next.
Comment 6 Terry Heatlie 2003-02-22 00:21:05 UTC
The new implementation of getInstance() has now been checked in.
All the tests copied from the core ErrorManager unit test now
pass.
Comment 7 Terry Heatlie 2003-02-22 01:10:23 UTC
I tried the TestLogger test case, which was cited when the bug
was logged, and it now seems to work okay.
Comment 8 Terry Heatlie 2003-02-24 18:34:26 UTC
A further tweak to getInstance() was made, and a test case added
to the unit test.  I believe we now fully duplicate getInstace()
behaviour from the core.  I had slightly mis-understood the correct
behaviour.  In fact, two calls to getInstance() with the same
name are supposed to return *two distinct errormanagers* not
the same one.  Certain of the messages from each em are uniquified
by adding #<number> to them.  Our EM gets this for free, because
the core EM to which we delegate already does this.  Test case is
testSameNames()...
Comment 9 Jesse Glick 2003-02-24 19:54:34 UTC
It does not matter whether getInstance() creates a new instance or
reuses one. The #1, #2, #3 etc. syntax is intentionally not tested
since it is just an implementation detail that may go away - I found
it helpful when reinstalling modules frequently to be able to tell
whether a given message came from the currently installed version of a
module, or some older version that is supposed to now be off.