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.
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.
Raised priority to P2, we'll try to plan this task for the next release
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.
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.
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.
Created attachment 28782 [details] The HTML description with usecases and proposed usage
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.
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.
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.
Sorry, never meant to mark this as fixed.
Leaving it back as it was
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.
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
Created attachment 29020 [details] Diff showing all usages of ErrorManager.UNKNOWN and ErrorManager.notify(Throwable) ~220 files in ~22 modules
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.
I have branched core openide and xtest at BLD200603191900 and create a branch logging_35067 - the basic implementation is available there.
Created attachment 29374 [details] List of warnings in all non-platform clusters that need to be fixed about 1200
Changes in trunk till BLD200603281800 merged to the logging_35067 branch.
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.
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.
Branch in openide and core made up to date with BLD200606011800
apisupport/jackpotrules has been branched to noerrmgr_35067 with rootnoerrmgr_35067_root or BLD200606061800
"Bringing up to date with BLD200606081800" openide core apisupport/jackpotrules/
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.
Made up to date with BLD200606141800
Created attachment 31075 [details] The current diff of the branch showing the API changes
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.
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.
Up-to-date with BLD200606191800
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
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
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.
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.