Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 35067 - Permit ErrorManager to be replaced w/ java.util.logging & Throwable.cause
Permit ErrorManager to be replaced w/ java.util.logging & Throwable.cause
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: -- Other --
6.x
All All
: P1 (vote)
: 6.x
Assigned To: Jaroslav Tulach
issues@platform
TCR
: API, API_REVIEW
Depends on: 17747 31442 56311 73882 75909
Blocks: 30191
  Show dependency treegraph
 
Reported: 2003-07-22 22:30 UTC by Jesse Glick
Modified: 2010-03-17 05:18 UTC (History)
11 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
The HTML description with usecases and proposed usage (7.61 KB, text/html)
2006-02-07 19:30 UTC, Jaroslav Tulach
Details
Diff showing all usages of ErrorManager.UNKNOWN and ErrorManager.notify(Throwable) ~220 files in ~22 modules (266.05 KB, patch)
2006-02-25 12:26 UTC, Jaroslav Tulach
Details | Diff
List of warnings in all non-platform clusters that need to be fixed about 1200 (233.51 KB, text/plain)
2006-03-23 09:57 UTC, Jaroslav Tulach
Details
The current diff of the branch showing the API changes (222.78 KB, patch)
2006-06-15 13:31 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2003-07-22 22:30:59 UTC
My list of probable required steps on nbdev:

1. Use of logging proper. Mostly, we use
ErrorManager.log for tracing, what would be listed
as FINE - FINEST in logging.Level. I think these
usages could be pretty easily replaced. RefactorIt
might come in handy here. Where you write in NB

err.log("something: " + obj);

you need to replace e.g.

logger.log(Level.FINER, "something: {0}", obj);

and so on. The EM.getInstance calls maps well to
the Logger namespace. EM.isLoggable has an
equivalent, but in most cases you can just call
Logger.log, since the format system prevents
excessive work from being done when log messages
will not be used. Occasionally a whole block of
work is being done just for logging, which would
indeed map to Logger.isLoggable.

2. Is there any reason to keep the NbErrorManager
impl of logging (i.e. formatting)? I like the
format output a bit better as it is more concise.
However java.util.logging makes it easy to plug in
alternative formatters, which is nice. So the
custom formatting could be dropped entirely, or
made JDK 1.4 compliant.

3. The other half of ErrorManager is throwable
annotation. Starting with adding stack traces:
most uses of annotate(Throwable,Throwable) could
be replaced with JDK 1.4's initCause(). There are
a few cases where we actually add multiple
throwable annotations to one master throwable,
which JDK 1.4 does not directly support - e.g.
when collecting SystemAction deser failures during
a DataLoader deser. Fortunately these instances
are rare and can probably be handled more simply.

4. Another kind of common annotation is localized
messages; ErrorManager supports attaching them,
and NbErrorManager knows how to search for them.
We could use Throwable.getLocalizedMessage to
distinguish localized from unlocalized messages -
unfortunately this typically requires creating
lots of anonymous exception subclasses. Some other
tricks may be possible, e.g. using specially
marked detail messages that refer to a resource
bundle name and key, and format arguments...? Or
just prefixing localized messages with "*" to
ensure they are shown to the user? Or using HTML
for all user-visible messaging? How to add
additional messages to an existing throwable?
Needs thought.

5. ErrorManager supports annotation of severity on
exceptions, which the JDK does not. Again, could
use some magic stuff in the detail message,
perhaps; needs thought. EM supports this kind of
annotation both from the exception thrower and
catcher - the wisdom of this decision could be
revisited, but currently a bunch of code relies on
it (e.g. property sheet, file handling operations,
etc.).

6. NbErrorManager registers itself as the default
thread group exception handler, so it can report
exceptions the way it likes. For example, to stack
traces it adds the useful "[caught]" pointer. For
user-visible errors, it pops up a dialog. I think
this can still be done without ErrorManager being
visible as an API for *uncaught exceptions*. What
about exceptions that are caught in the code and
just wish to be notified properly, and continue?
You could call

} catch (IOException e) {
    // possibly mark as lower severity etc.
    Thread t = Thread.currentThread();
    t.getThreadGroup().uncaughtException(t, e);
}

though it looks a little clumsy. You could perhaps
use Logger to notify the system of caught
exceptions, and rely on having a special handler
and formatter that can not only print useful stack
traces to the log but  present user-visible
problems in a dialog.

7. Replacing uses of EM for exception handling in
the code base with other still-TBD mechanisms.
Again, a big refactoring, a major project unless
you have some really good tools, and still a lot
of manual sanity checking.

8. Going back over a lot of old EM-related bugs
and confirming that the refactored code still
behaves sanely - that user-visible problems are
reported politely, that developer-oriented
problems are sent to ide.log with adequate
details, etc.
Comment 1 _ ttran 2005-12-18 20:58:41 UTC
Raised priority to P2, we'll try to plan this task for the next release
Comment 2 Jaroslav Tulach 2005-12-20 10:33:29 UTC
As part of work on issue 56311 most of the goals outlined here have been 
addressed. The patch 
http://www.netbeans.org/nonav/issues/showattachment.cgi/27921/Y.diff      
contains change to ErrorManager documentation:      
1. it deprecates the class     
2. it changes the examples there to use java.util.logging     
     
Here is my evaluation of how the goals stated herein are solved by the above 
mentioned patch:    
    
#1 - indeed. Using Logger.log(Level.FINE) is direct equivalent of    
ErrorManager.log(INFORMATIONAL)    
    
#2 - the patch keeps the formating and other logic in core in order to support   
all "special tricks", like the AWT exception handler, the way annotation   
used to be extracted, showing the ErrorManager.USER (now Level.INFO) exception   
dialogs, etc. Originally I tried to reuse one of the java.util.logging.Handler   
but the benefit is low, its simpler to write Handler.publish(LogRecord) and   
that is what the patch does.   
   
#3 - Yes. initCause is a way to chain annotation and it supports multiple  
chains[1] - one can always find the last getCause() and add initCause to it, 
seems to work.  
  
#4 - Throwable.getLocalizedMessage is supported (it always used to be since 
3.0 and due to #2 remains supported even now), but there is support for 
localization in LogRecord, so the patch proposes a way to attach localized 
LogRecord to annotation. Imho acceptable solution, but indeed an API to 
review. 
  
#5 - Solved by the same way as #4 - e.g. by ability to attach LogRecord to 
throwable 
 
#6 - Logger.getAnnonymousLogger().log(Level.SEVERE, "a msg", throwable) or 
some other Level, or some named logger, is a way to send uncaught exceptions 
to the central logger. 
  
#7 - The patch provides a 1-1 mapping from a use of ErrorManager method to the 
"new style", so it should be possible to automate that having good enough 
tool. This may but need not happen - the semantics of the old calls and new 
replacements are the same. 
 
#8 - The old NbErrorManagerTest works fine with new code which is an indirect 
indication that the rewrite is good. Also basing the rewrite on the old code 
and not doing it from scratch is another indication that the behaviour is 
going to remain compatible. 
 
Jesse asked an important question in issue 56311, but as this issue is an 
umbrella for api review now, I'd like to provide answer here: 
 
Re: "Logging folder in layers vs. properties" - we can support mapping from 
-J-Dorg.something.level=100 to property that influences the Logger. The needed 
thing however is that the property ends with ".level"[2]. Then the "logging" 
folder would not needed anymore, imho. 
 
  
[1] possibly in wrong order, but that is not that important, moreover could be 
fixed if really needed. 
[2] otherwise we would need to take all properties from System.getProperty() 
and append .level to them and pass them to LogManager.readConfiguration, I am 
not sure what the LogManager would do with all the properties we have. 
Comment 3 Jesse Glick 2005-12-20 16:29:23 UTC
All sounds reasonable to me.

The use of Throwable implements Lookup.Provider<LogRecord> is a little weird. I
think it would be overkill if it is just used to provide localized messages,
though if it is needed for other things it may be OK, so long as there is a more
comfortable way of doing it from the client perspective.
Comment 4 Jesse Glick 2006-02-04 16:02:29 UTC
Still find localized message usage weird - not terrible, just no obvious reason
for it to work that way. To step back a bit, here are all the ways I can think
of that you would handle a catch of an exception:

0. Should not be possible; rethrow as an AssertionError, or assert false : exc.

1. Can happen a lot, and is not generally interesting at all. Ignore with a
comment, or send to your Logger at FINER or something, so it will appear in a
log only if you enable logging on this component.

2. Can happen, but should not concern user. exc.printStackTrace() is fine.

3. Is something the user should be made aware of in a structured way. (E.g. IAE
from a bean setter in property sheet, or IOE loading a project in Open Project.)
Subcases:

3a. exc.localizedMessage != exc.message. So, show exc.localizedMessage.

3b. Same as (3a) but for exc.initCause() or exc.initCause().initCause() etc.
Show the first such localizedMessage encountered.

3c. No special localizedMessage. But user must be shown something, so show them
exc.message.

3d. No special localizedMessage, but user could just be shown a generic error
message that does not incorporate the exception at all.

Now cases (0), (1), and (2) don't really require any special API, I think. (3)
is the interesting part. What is interesting to note, re. your patch, is that
the use case of (3) does *not* need to involve java.util.logging at all, or any
default handler - the exception is thrown from one piece of code, caught in
another, and displayed to the user in a special GUI. Uncaught exceptions can
just be printStackTrace'd somewhere (i.e. fallback handler in core should act
like #1 - which is the default behavior for Java, meaning we could in fact
delete it). The tricky parts of (3) are

3.1. The thrower should find it easy to specify a localizedMessage, preferably
without making an anon inner subclass of the exception.

3.2. The catcher should find it easy to search for a localizedMessage among
initCause subexceptions.

3.3. We should retain b/c with ErrorManager.annotate. (Mostly for legacy thrower
code; the amount of catcher code affected by (3) is I think pretty small. It is
not a very common use case.)

So my suggestion:

S1. Kill NotifyException, the little error icon, etc. If something goes wrong,
it will go into your log file. If you need to know about it, some piece of code
will tell you. We can always supply an optional module to display notifications
about new stack traces in your log file for those people who feel a strong urge
to know.

S2. Create a new utility method somewhere (ErrorManager? Utilities? some new class?)

/**
 * Look for a localized message in a throwable or its root cause(s).
 * First, if the throwable or any root cause(s) has a localizedMessage
 * which differs from its message, use that (escaped to HTML).
 * Second, if the throwable or any root cause(s) has a message which
 * begins with "<html>", use that as is.
 * Third, if requireLocalized is false, use the first non-null message
 * from the throwable or any root cause(s).
 * Fourth, if requireLocalized is false, use toString of the throwable.
 * Fifth, if requireLocalized is true, use null.
 */
public static String findLocalizedMessage(Throwable exc, boolean requireLocalized);

S3. The core impl of ErrorManager.annotate (using a
WeakHasHap<Throwable,Annotation>) can be moved into the openide version; all
deprecated anyway. findLocalizedMessage will also as a first step look for a
localized message annotation from EM among the throwable or its cause(s).

This suggestion keeps the impl pretty simple, no Lookup, and I think does what
we need. Thrower usage is simple, e.g. (here demonstrating also rethrowing
unlocalized exceptions caught from elsewhere):

File f = ...;
SAXException e = ...;
throw (IOException) new IOException(e.toString()) {
    public String getLocalizedMessage() {
        return /*XXX I18N*/ "Error encountered parsing " + f;
    }
}.initCause(e);

or more simply

throw (IOException) new IOException(/*XXX I18N*/ "<html>Error encountered
parsing <code>" + f + "</code>").initCause(e);

Catcher usage is simple. For (3c):

catch (IOException e) {
    errorField.setText(XXX.findLocalizedMessage(e, false));
}

For (3d):

catch (IllegalArgumentException e) {
    String message = XXX.findLocalizedMessage(e, true);
    if (message == null) {
        message = /*XXX I18N*/ "Invalid input, please try again.";
    }
    DialogDisplayer.notify(new NotifyDescriptor.Message(message,
NotifyDescriptor.ERROR_MESSAGE));
}

Old (ErrorManager-using) thrower code will still work as expected, since it just
added EM localized annotations which are still detected. Old catcher code (if
there is any) may still work too, since the usual pattern was to work more or
less like the new XXX.findLocalizedMessage, though it might be confused by HTML
messages (depending on what it does with them).

Just some thoughts for an alternative approach. So long as routine usage for use
cases 0 through 3 is kept simple, I don't have a strong feeling about it.
Comment 5 Jaroslav Tulach 2006-02-07 19:30:10 UTC
Created attachment 28782 [details]
The HTML description with usecases and proposed usage
Comment 6 Jaroslav Tulach 2006-02-07 19:41:20 UTC
Thanks Jesse for your comments, but as I got a bit confused, I tried to step 
back and start with the usecases. Here is the document that imho describes 
what we want and (sorry it should not) also describes how to achieve that. 
 
I do agree that the Lookup.Provider was not nice idea. That is why I am 
proposing org.openide.util.Exceptions helper class that clients can use. 
 
I do not thing System.err.println or exp.printStackTrace() is something we 
should support. The fact that it ends up in the same log file is more an 
accident than something to be proud of. So I suggest to use 
Logger.log(Level.FINEST, ..., ex). This has the benefit of being configurable, 
which ex.pst() lacks. 
 
I agree with 3.1, 3.2, 3.3 and I believe I can solve it with the introduction 
of the Exceptions class. It would have bunch of annotate methods, mostly 
copied from ErrorManager and one find method that will find the annotations. I 
propose to use LogRecord for the annotation, so the find method would has 
signature: LogRecord[] find(Throwable); This is the simplest way how to align 
with my patch and remove the need for Lookup.Provider from all sample usages. 
 
I do not think using DialogDescriptor has any benefit, so I would stick with 
current Logger.log(Level...., ex). It is imho working well and more pluggable 
than DialogDisplayer. 
 
If you fell I have not understand something important from your writings, 
please tell me or better send me patch to the logging.html file I've just 
attached. 
 
Btw. I will announce a review tomorrow, schedule it for next week's wednesday, 
if ok and probably have you, Petr Jiricka, Jiri Skrivanek, and one more guy as 
reviewers. 
Comment 7 Jaroslav Tulach 2006-02-08 16:23:15 UTC
Let's start the logging without error manager review. I have created a  
skeleton of optinion. It contains most of the information, the patch and the  
howto document about the way to do logging with the new system. It also  
contains few open questions. See:  
http://openide.netbeans.org/tutorial/reviews/opinions_35067.html  
  
The reviewers shall include: Jesse, Jiri, Petr and Radim. The inception review 
is going to be on Feb23, 15.00cet. 
Comment 8 Jaroslav Tulach 2006-02-08 16:29:37 UTC
Let's start the logging without error manager review. I have created a  
skeleton of optinion. It contains most of the information, the patch and the  
howto document about the way to do logging with the new system. It also  
contains few open questions. See:  
http://openide.netbeans.org/tutorial/reviews/opinions_35067.html  
  
The reviewers shall include: Jesse, Jiri, Petr and Radim. The inception review 
is going to be on Feb23, 15.00cet. 
Comment 9 misterm 2006-02-08 18:19:31 UTC
I am afraid backwards compatibility might get broken if people tried to make 
code that used java.util.logging delegate to the ErrorManager API.

For instance, check this:

https://thinnbeditor.dev.java.net/source/browse/thinnbeditor/thinnbeditor/src/ne
t/java/dev/thinnbeditor/ThinletVisualEditorInstall.java?
rev=1.1&view=auto&content-type=text/vnd.viewcvs-markup
https://thinnbeditor.dev.java.net/source/browse/thinnbeditor/thinnbeditor/src/ne
t/java/dev/thinnbeditor/logging/LoggerAdapter.java?rev=1.1&view=auto&content-
type=text/vnd.viewcvs-markup

These workarounds may lead to StackOverflowError depending on how the proposed 
solution is implemented.
Comment 10 misterm 2006-02-08 18:19:57 UTC
I am afraid backwards compatibility might get broken if people tried to make 
code that used java.util.logging delegate to the ErrorManager API.

For instance, check this:

https://thinnbeditor.dev.java.net/source/browse/thinnbeditor/thinnbeditor/src/ne
t/java/dev/thinnbeditor/ThinletVisualEditorInstall.java?
rev=1.1&view=auto&content-type=text/vnd.viewcvs-markup
https://thinnbeditor.dev.java.net/source/browse/thinnbeditor/thinnbeditor/src/ne
t/java/dev/thinnbeditor/logging/LoggerAdapter.java?rev=1.1&view=auto&content-
type=text/vnd.viewcvs-markup

These workarounds may lead to StackOverflowError depending on how the proposed 
solution is implemented.
Comment 11 misterm 2006-02-08 18:20:39 UTC
Sorry, never meant to mark this as fixed.
Comment 12 misterm 2006-02-08 18:21:46 UTC
Leaving it back as it was
Comment 13 Petr Jiricka 2006-02-09 09:41:16 UTC
My comments:

PJ1: Please do not deprecate ErrorManager for now. The codebase already has a
lot of deprecation warnings, and adding many more will only obscure the existing
ones and will make it harder to distinguish the more important ones.

PJ2: Will it be possible to replace the old patters by the new patterns
semi-automatically?

PJ3: Do I understand it correctly that ths plan is to stop showing the exception
window for some logging levels as it is done now, or will this behavior be
preserved? I do not agree with suppressing the exception window, as it will make
many bugs harder to find, and we will get fewer bug reports from both internal
and external testing community.
Comment 14 Jaroslav Tulach 2006-02-13 16:55:00 UTC
Thank you for your comments guys. Here are my replies: 
 
PJ3: No UI changes planned: 
http://www.netbeans.org/source/browse/openide/www/tutorial/reviews/opinions_35067.html?r1=1.2&r2=1.3 
 
PJ2: I guess regexp would convert about 1/4 of usages. To get better 
automation we would need some semantic level processing tools. I've contacted 
Tom Ball and asked him if his jackpot can help. 
 
PJ1: Ok, let's leave the deprecation of ErrorManager till the whole NetBeans 
code base is converted: 
http://www.netbeans.org/source/browse/openide/www/tutorial/reviews/opinions_35067.html?r1=1.3&r2=1.4 
 
misterm: Your examples have to work and cannot throw StackOverFlow, thanks for 
pointing this case out: 
http://www.netbeans.org/source/browse/openide/www/tutorial/reviews/opinions_35067.html?r1=1.4&r2=1.5 
 
Comment 15 Jaroslav Tulach 2006-02-25 12:26:29 UTC
Created attachment 29020 [details]
Diff showing all usages of ErrorManager.UNKNOWN and ErrorManager.notify(Throwable) ~220 files in ~22 modules
Comment 16 Jesse Glick 2006-03-09 15:30:34 UTC
I think some usages could be refined further. For example, the first one:

org.netbeans.modules.ant.freeform.Util.err.annotate(e, ErrorManager.UNKNOWN,
"From <pattern> in " +
FileUtil.getFileDisplayName(project.getProjectDirectory().getFileObject(AntProjectHelper.PROJECT_XML_PATH)),
null, null, null); // NOI18N
org.netbeans.modules.ant.freeform.Util.err.notify(e);

could naturally be rewritten as

org.netbeans.modules.ant.freeform.Util.LOGGER.log(Level.WARNING, "From <pattern>
in " +
FileUtil.getFileDisplayName(project.getProjectDirectory().getFileObject(AntProjectHelper.PROJECT_XML_PATH)),
e);

Such a rewrite poses no problem at all.

Most other usages of .notify could and probably should have been using
EM.INFORMATIONAL, i.e. the exception is a problem somewhere which should perhaps
show a flashing error icon in the status bar and should probably show a stack
trace in log file, but the app is not broken. This is true of most caught
IOException's etc. I think that should be the default rewrite rule: from

ErrorManager.getDefault().notify(x);

to

Logger.getInstance(ThisClass.getName()).log(Level.WARNING, null, x);

Some other exceptions should really be treated as assert failures, e.g.

try {
    return new BeanInfo[] { Introspector.getBeanInfo(UniFileLoader.class) };
} catch (IntrospectionException ie) {
    ErrorManager.getDefault().notify(ie);
    return null;
}

Under what conditions would an IE be thrown here? Only if the NB installation is
completely corrupted or the JDK malfunctioning. I would recommend

try {
    return new BeanInfo[] { Introspector.getBeanInfo(UniFileLoader.class) };
} catch (IntrospectionException ie) {
    throw new AssertionError(ie);
}

Similarly, in most cases in NB code when we catch MalformedURLException it is
because someone had the brilliant idea to make this a checked exception. It is
rare for us to create a URL directly from external input. Usually a URL is
formed by calling e.g. File.toURI().toURL() which is not supposed to ever throw
this exception. So if you catch it, best to rethrow as an AssertionError.
Comment 17 Jaroslav Tulach 2006-03-20 17:13:54 UTC
I have branched core openide and xtest at BLD200603191900 and create a branch 
logging_35067 - the basic implementation is available there.
Comment 18 Jaroslav Tulach 2006-03-23 09:57:51 UTC
Created attachment 29374 [details]
List of warnings in all non-platform clusters that need to be fixed about 1200
Comment 19 Jaroslav Tulach 2006-03-29 04:39:22 UTC
Changes in trunk till BLD200603281800 merged to the logging_35067 branch. 
Comment 20 Jaroslav Tulach 2006-04-04 17:03:27 UTC
Phase I is integrated, so I am closing issue 56311. The state of the document 
review document currently is:
http://www.netbeans.org/nonav/source/browse/*checkout*/openide/www/tutorial/reviews/opinions_35067.html?rev=1.38
I am turning this issue into TCR to: Prepare and execute a plan that will 
allow ErrorManager to be fully deprecated and replaced by other APIs.
Comment 21 Jaroslav Tulach 2006-05-03 16:58:27 UTC
Branch noerrmgr_35067 branch created for openide and core rooted at 
noerrmgr_35067_root which is going to contain proposed changes that will allow 
to fully deprecate ErrorManager.

Comment 22 Jaroslav Tulach 2006-06-03 04:55:26 UTC
Branch in openide and core made up to date with BLD200606011800
Comment 23 Jaroslav Tulach 2006-06-07 14:40:40 UTC
apisupport/jackpotrules has been branched to noerrmgr_35067 with 
rootnoerrmgr_35067_root or  BLD200606061800
Comment 24 Jaroslav Tulach 2006-06-09 10:02:32 UTC
"Bringing up to date with  BLD200606081800"  openide core 
apisupport/jackpotrules/
Comment 25 Jaroslav Tulach 2006-06-15 10:36:54 UTC
As indicated in the opinion document:
http://www.netbeans.org/source/browse/*checkout*/openide/www/tutorial/reviews/opinions_35067.html?rev=1.52
the goals for phase 3/2 are completed and I am convinced that it is a time to 
merge to trunk. I'd like to do the merge (plus documentation changes, removal 
of all usages of ErrorManager in platform cluster) next week. If there are no 
objections, I'll start on Wednesday.

Comment 26 Jaroslav Tulach 2006-06-15 13:23:39 UTC
Made up to date with BLD200606141800
Comment 27 Jaroslav Tulach 2006-06-15 13:31:47 UTC
Created attachment 31075 [details]
The current diff of the branch showing the API changes
Comment 28 Jesse Glick 2006-06-15 16:43:05 UTC
Could you do redo the diff please? There are dozens of files that are not
actually modified in the branch which seem to have been included accidentally;
look at it.
Comment 29 Jesse Glick 2006-06-20 00:10:07 UTC
TopLoggingLookupTest could use MockServices.


Need comment in @deprecated tag in ErrorManager. Also please use @Deprecated
annotation.


Need Javadoc in Exceptions class.


The magic interface of Callable<LogRecord[]> ought to be documented somewhere.


Otherwise looks reasonable, though I did not try to understand all of the impl.
Comment 30 Jaroslav Tulach 2006-06-20 10:53:54 UTC
Up-to-date with BLD200606191800
Comment 31 Jaroslav Tulach 2006-06-21 07:43:47 UTC
Checking in openide/dialogs/apichanges.xml;
/shared/data/ccvs/repository/openide/dialogs/apichanges.xml,v  <--  
apichanges.xml
new revision: 1.6; previous revision: 1.5
done
Checking in openide/dialogs/manifest.mf;
/shared/data/ccvs/repository/openide/dialogs/manifest.mf,v  <--  manifest.mf
new revision: 1.8; previous revision: 1.7
done
Checking in 
core/startup/test/unit/src/org/netbeans/core/startup/TopLoggingTest.java;
/shared/data/ccvs/repository/core/startup/test/unit/src/org/netbeans/core/startup/TopLoggingTest.java,v  
<--  TopLoggingTest.java
new revision: 1.7; previous revision: 1.6
done
Checking in 
core/startup/test/unit/src/org/netbeans/core/startup/TopLoggingLookupTest.java;
/shared/data/ccvs/repository/core/startup/test/unit/src/org/netbeans/core/startup/TopLoggingLookupTest.java,v  
<--  TopLoggingLookupTest.java
new revision: 1.2; previous revision: 1.1
done
Checking in apisupport/jackpotrules/nbproject/project.xml;
/shared/data/ccvs/repository/apisupport/jackpotrules/nbproject/project.xml,v  
<--  project.xml
new revision: 1.3; previous revision: 1.2
done
Checking in apisupport/jackpotrules/nbproject/project.properties;
/shared/data/ccvs/repository/apisupport/jackpotrules/nbproject/project.properties,v  
<--  project.properties
new revision: 1.2; previous revision: 1.1
done
Checking in core/src/org/netbeans/core/NotifyException.java;
/shared/data/ccvs/repository/core/src/org/netbeans/core/NotifyException.java,v  
<--  NotifyException.java
new revision: 1.73; previous revision: 1.72
done
Checking in core/src/org/netbeans/core/NbErrorManager.java;
/shared/data/ccvs/repository/core/src/org/netbeans/core/NbErrorManager.java,v  
<--  NbErrorManager.java
new revision: 1.62; previous revision: 1.61
done
Checking in core/src/org/netbeans/core/Bundle.properties;
/shared/data/ccvs/repository/core/src/org/netbeans/core/Bundle.properties,v  
<--  Bundle.properties
new revision: 1.421; previous revision: 1.420
done
Checking in core/startup/src/org/netbeans/core/startup/Bundle.properties;
/shared/data/ccvs/repository/core/startup/src/org/netbeans/core/startup/Bundle.properties,v  
<--  Bundle.properties
new revision: 1.17; previous revision: 1.16
done
Checking in core/startup/src/org/netbeans/core/startup/Main.java;
/shared/data/ccvs/repository/core/startup/src/org/netbeans/core/startup/Main.java,v  
<--  Main.java
new revision: 1.26; previous revision: 1.25
done
Checking in core/startup/src/org/netbeans/core/startup/TopLogging.java;
/shared/data/ccvs/repository/core/startup/src/org/netbeans/core/startup/TopLogging.java,v  
<--  TopLogging.java
new revision: 1.14; previous revision: 1.13
done
Checking in openide/dialogs/src/org/openide/NotifyDescriptor.java;
/shared/data/ccvs/repository/openide/dialogs/src/org/openide/NotifyDescriptor.java,v  
<--  NotifyDescriptor.java
new revision: 1.4; previous revision: 1.3
done
Checking in openide/dialogs/src/org/openide/DialogDisplayer.java;
/shared/data/ccvs/repository/openide/dialogs/src/org/openide/DialogDisplayer.java,v  
<--  DialogDisplayer.java
new revision: 1.3; previous revision: 1.2
done
Checking in 
core/test/unit/src/org/netbeans/core/NotifyExceptionBundle.properties;
/shared/data/ccvs/repository/core/test/unit/src/org/netbeans/core/NotifyExceptionBundle.properties,v  
<--  NotifyExceptionBundle.properties
new revision: 1.2; previous revision: 1.1
done
Checking in core/test/unit/src/org/netbeans/core/NbErrorManagerTest.java;
/shared/data/ccvs/repository/core/test/unit/src/org/netbeans/core/NbErrorManagerTest.java,v  
<--  NbErrorManagerTest.java
new revision: 1.10; previous revision: 1.9
done
Checking in core/test/unit/src/org/netbeans/core/NotifyExceptionTest.java;
/shared/data/ccvs/repository/core/test/unit/src/org/netbeans/core/NotifyExceptionTest.java,v  
<--  NotifyExceptionTest.java
new revision: 1.2; previous revision: 1.1
done
Checking in 
apisupport/jackpotrules/test/unit/src/org/netbeans/modules/apisupport/jackpotrules/ErrorManagerTest.java;
/shared/data/ccvs/repository/apisupport/jackpotrules/test/unit/src/org/netbeans/modules/apisupport/jackpotrules/ErrorManagerTest.java,v  
<--  ErrorManagerTest.java
new revision: 1.2; previous revision: 1.1
done
Checking in 
apisupport/jackpotrules/test/unit/src/org/netbeans/modules/apisupport/jackpotrules/JackpotUtils.java;
/shared/data/ccvs/repository/apisupport/jackpotrules/test/unit/src/org/netbeans/modules/apisupport/jackpotrules/JackpotUtils.java,v  
<--  JackpotUtils.java
new revision: 1.2; previous revision: 1.1
done
Checking in openide/util/src/org/openide/util/doc-files/logging.html;
/shared/data/ccvs/repository/openide/util/src/org/openide/util/doc-files/logging.html,v  
<--  logging.html
new revision: 1.5; previous revision: 1.4
done
Checking in core/src/META-INF/services/java.util.logging.Handler;
/shared/data/ccvs/repository/core/src/META-INF/services/java.util.logging.Handler,v  
<--  java.util.logging.Handler
new revision: 1.2; previous revision: 1.1
done
Removing core/src/META-INF/services/org.openide.ErrorManager;
/shared/data/ccvs/repository/core/src/META-INF/services/org.openide.ErrorManager,v  
<--  org.openide.ErrorManager
new revision: delete; previous revision: 1.1
done
Checking in core/arch/arch-core-launcher.xml;
/shared/data/ccvs/repository/core/arch/arch-core-launcher.xml,v  <--  
arch-core-launcher.xml
new revision: 1.44; previous revision: 1.43
done
Checking in 
apisupport/jackpotrules/src/org/netbeans/modules/apisupport/jackpotrules/annotate-to-initcause.rules;
/shared/data/ccvs/repository/apisupport/jackpotrules/src/org/netbeans/modules/apisupport/jackpotrules/annotate-to-initcause.rules,v  
<--  annotate-to-initcause.rules
new revision: 1.2; previous revision: 1.1
done
Checking in openide/util/apichanges.xml;
/shared/data/ccvs/repository/openide/util/apichanges.xml,v  <--  
apichanges.xml
new revision: 1.15; previous revision: 1.14
done
Checking in openide/util/nbproject/project.properties;
/shared/data/ccvs/repository/openide/util/nbproject/project.properties,v  <--  
project.properties
new revision: 1.16; previous revision: 1.15
done
Checking in openide/util/test/unit/src/org/openide/util/ExceptionsTest.java;
/shared/data/ccvs/repository/openide/util/test/unit/src/org/openide/util/ExceptionsTest.java,v  
<--  ExceptionsTest.java
new revision: 1.2; previous revision: 1.1
done
Checking in openide/util/src/org/openide/ErrorManager.java;
/shared/data/ccvs/repository/openide/util/src/org/openide/ErrorManager.java,v  
<--  ErrorManager.java
new revision: 1.8; previous revision: 1.7
done
Checking in 
openide/util/test/unit/src/org/openide/ErrorManagerDelegatesToLoggingTest.java;
/shared/data/ccvs/repository/openide/util/test/unit/src/org/openide/ErrorManagerDelegatesToLoggingTest.java,v  
<--  ErrorManagerDelegatesToLoggingTest.java
new revision: 1.3; previous revision: 1.2
done
Checking in openide/util/src/org/openide/util/Exceptions.java;
/shared/data/ccvs/repository/openide/util/src/org/openide/util/Exceptions.java,v  
<--  Exceptions.java
new revision: 1.2; previous revision: 1.1
Comment 32 Jiri Skrivanek 2006-07-21 11:40:56 UTC
XTest update - added XTestIDEHandler which is registered before tests are
executed. XTestErrorManager can be removed later when it will be removed from IDE.

Checking in plugins_src/ide/src/org/netbeans/xtest/plugin/ide/MainWithExec.java;
/cvs/xtest/plugins_src/ide/src/org/netbeans/xtest/plugin/ide/MainWithExec.java,v
 <--  MainWithExec.java
new revision: 1.10; previous revision: 1.9
done
Checking in plugins_src/ide/src/org/netbeans/xtest/plugin/ide/XTestIDEHandler.java;
/cvs/xtest/plugins_src/ide/src/org/netbeans/xtest/plugin/ide/XTestIDEHandler.java,v
 <--  XTestIDEHandler.java
initial revision: 1.1
done
Checking in
plugins_src/ide/test/unit/src/org/netbeans/xtest/plugin/ide/test/XTestIDEHandlerCheckTest.java;
/cvs/xtest/plugins_src/ide/test/unit/src/org/netbeans/xtest/plugin/ide/test/XTestIDEHandlerCheckTest.java,v
 <--  XTestIDEHandlerCheckTest.java
initial revision: 1.1
done
Checking in
plugins_src/ide/test/unit/src/org/netbeans/xtest/plugin/ide/test/XTestIDEHandlerTest.java;
/cvs/xtest/plugins_src/ide/test/unit/src/org/netbeans/xtest/plugin/ide/test/XTestIDEHandlerTest.java,v
 <--  XTestIDEHandlerTest.java
initial revision: 1.1
done
Checking in plugins_src/ide/build.xml;
/cvs/xtest/plugins_src/ide/build.xml,v  <--  build.xml
new revision: 1.22; previous revision: 1.21
done
Comment 33 Jesse Glick 2010-03-16 16:40:31 UTC
Something was broken by the big replace in JavaHelp.java:

     private static void warnBadID(String id) {
         // PLEASE DO NOT COMMENT OUT...localized warning
-        Installer.err.log(ErrorManager.WARNING, NbBundle.getMessage(...));
+        Installer.log.fine(NbBundle.getMessage(...));
     }

meaning that a message that used to be printed to console now is not. I will fix this instance (core-main #2c406664371f), but there could be thousands of other cases no one knows about; next time need to review diffs more carefully, I guess.
Comment 34 Quality Engineering 2010-03-17 05:18:15 UTC
Integrated into 'main-golden', will be available in build *201003170201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/2c406664371f
User: Jesse Glick <jglick@netbeans.org>
Log: Warning message accidentally downgraded in #35067.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo