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.
Summary: | Permit ErrorManager to be replaced w/ java.util.logging & Throwable.cause | ||
---|---|---|---|
Product: | platform | Reporter: | Jesse Glick <jglick> |
Component: | -- Other -- | Assignee: | Jaroslav Tulach <jtulach> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | breh, dstrupl, hmichel, jglick, jskrivanek, misterm, mkrauskopf, pjiricka, ppisl, rkubacki, ttran |
Priority: | P1 | Keywords: | API, API_REVIEW |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | 17747, 31442, 56311, 73882, 75909 | ||
Bug Blocks: | 30191 | ||
Attachments: |
The HTML description with usecases and proposed usage
Diff showing all usages of ErrorManager.UNKNOWN and ErrorManager.notify(Throwable) ~220 files in ~22 modules List of warnings in all non-platform clusters that need to be fixed about 1200 The current diff of the branch showing the API changes |
Description
Jesse Glick
2003-07-22 22:30:59 UTC
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. 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. 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. |