Community
Participate
Working Groups
I20080613-2000 Not sure if this belongs to JDT/Debug or Platform/Debug. I saw this error message several times today in my error log but I'm not yet sure how to reproduce it. -- Error Details -- Date: Sun Jul 06 16:04:00 CEST 2008 Message: No property tester contributes a property org.eclipse.debug.ui.projectNature to type class org.eclipse.jdt.internal.junit.model.TestCaseElement Severity: Error Plugin: org.eclipse.core.expressions
Moving to JUI for comment. The property tester in question (projectNature) is contributed by org.eclipse.debug.ui.
Cannot reproduce this problem. If you can, please reopen with steps to reproduce.
*** Bug 249756 has been marked as a duplicate of this bug. ***
Markus, any idea?
Benjamin and Olivier: Did this happen in a plain Eclipse SDK, or did you have other plug-ins installed (e.g. Mylyn or Jazz)? It looks like somebody contributed an adapter factory for TestCaseElement or one of its supertypes. The only references to <test property="org.eclipse.debug.ui.projectNature" [..]> I could find in the SDK is in the o.e.pde.ui plug-in, but those look OK. Unfortunately, there's no stacktrace, probably because the caller used the anti-pattern try { /*...*/ } catch (CoreException e) { XXXPlugin.log(e.getStatus()); } to swallow the stack. If somebody gets this from time to time, I could add some debug switches to write out more logging to stdout when this happens again.
Markus, at least my installation is always the SDK+Mylyn so maybe they are the "bad guys" in this case.
Markus, (In reply to comment #5) > Benjamin and Olivier: Did this happen in a plain Eclipse SDK, or did you have > other plug-ins installed (e.g. Mylyn or Jazz)? It looks like somebody > contributed an adapter factory for TestCaseElement or one of its supertypes. I use jdt/ui bundles + jdt/core tools + eclemma. > If somebody gets this from time to time, I could add some debug switches to > write out more logging to stdout when this happens again. Please do. If I get it again, I would definitely report more details.
Benjamin and Olivier: you could start a fresh workspace and import all plug-ins. Then search the plugin.xml files for test property="org.eclipse.debug.ui.projectNature which will probably reveal the problematic contribution.
> > If somebody gets this from time to time, I could add some debug switches to > > write out more logging to stdout when this happens again. > Please do. If I get it again, I would definitely report more details. I added a nested exception to the CoreException we throw in TypeExtensionManager.getProperty(..). That should reveal the location where the stacktrace of the original exception is lost. No debug switches required.
(In reply to comment #9) > I added a nested exception to the CoreException we throw in > TypeExtensionManager.getProperty(..). That should reveal the location where the > stacktrace of the original exception is lost. No debug switches required. This change causes slight slowdown on the performance tests that measure editor activation, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=258253#c12. Is that change still necessary - seems like there was no activity on this bug in about 6 months?
I added a debug option: org.eclipse.core.expressions/debug/TypeExtensionManager=false The debug code will now only be executed if this is set to "true".
> This change causes slight slowdown on the performance tests that measure editor > activation, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=258253#c12. Contributions are buggy in the first place if they cause such exceptions. I filed bug 273583 for the one that happen in that scenario.
