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.
Build: NetBeans IDE Dev (Build 20120425-03ec8561ca75) VM: Java HotSpot(TM) Client VM, 22.1-b02, Java(TM) SE Runtime Environment, 1.7.0_03-b04 OS: Linux Stacktrace: java.lang.NullPointerException at org.eclipse.core.internal.runtime.ResourceTranslator.getResourceBundle(ResourceTranslator.java:69) at org.eclipse.core.internal.runtime.ResourceTranslator.getResourceBundle(ResourceTranslator.java:61) at org.eclipse.core.internal.registry.osgi.EclipseBundleListener.addBundle(EclipseBundleListener.java:177) at org.eclipse.core.internal.registry.osgi.EclipseBundleListener.processBundles(EclipseBundleListener.java:90) at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.onStart(RegistryStrategyOSGI.java:224) at org.eclipse.core.internal.registry.ExtensionRegistry.<init>(ExtensionRegistry.java:725)
Created attachment 118765 [details] stacktrace
*** This bug has been marked as a duplicate of bug 211773 ***
Created attachment 118848 [details] stacktrace ide just started
Caused: org.osgi.framework.BundleException: Exception in org.eclipse.core.internal.registry.osgi.Activator.start() of bundle org.eclipse.equinox.registry.
This bug already has 5 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=187374
stopper for Beta
NPE because Activator.getDefault() returns null. The non-null return value is initialized in public void Activator.start(BundleContext context) - means the module probably have not activated successfully.
Consider possible similarity with bug 211744
Created attachment 118941 [details] stacktrace just started IDE
Probably duplicate of bug 211744.
Created attachment 118980 [details] stacktrace Just restarted IDE after updating modulemanager module.
Well I just encountered this running a build containing a353da65c6ed (attempted fix of bug #211744).
Need steps to reproduce.
We have 9 reports in last week from 5 different people ... you simply can't close such bug worksforme ... let's move it out of NB 7.2 Beta stopper list
Created attachment 119114 [details] stacktrace reopen IDE
This bug already has 10 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=187374
*** Bug 211773 has been marked as a duplicate of this bug. ***
FWIW this happens to me most of the time when I start the IDE in my long-term userdir.
Created attachment 119623 [details] stacktrace start IDE
*** Bug 212882 has been marked as a duplicate of this bug. ***
*** Bug 212823 has been marked as a duplicate of this bug. ***
(In reply to comment #18) > FWIW this happens to me most of the time when I start the IDE in my long-term > userdir. Can this be caused by corrupted OSGi caches? When it appears, does it appear on next start as well? Or is it completely random? If it is repeatable does removing of $cachedir/netigso-bundles help? Thanks.
I can reliably reproduce if I clean & build a module (php.project in my case). The exception appears just once (on the first IDE start).
(In reply to comment #22) > is it completely random? I am not sure I am able to reproduce at will; it does not happen in every IDE session.
Seems to happen mostly (only?) after a change in module set (e.g. updates) that would have triggered rebuild of caches, and then does not happen after a "clean" restart. I can reproduce merely by turning some plugin on or off and then restarting; no need for it to be an OSGi bundle, or depend on one. Removal of $cachedir/netigso-bundles before restart does not prevent the exception from occurring, nor indeed does using an entirely different cachedir.
Jesse, I can see there are various outdated modules present in your installation. Does this issue reproduce without them - e.g. with clean user directory? Btw. #213363 seems to be related to duplicated classes in the system, but I don't see anything like that in your case.
(In reply to comment #26) > there are various outdated modules present in your installation Sorry, which modules are you referring to? I always run with recent dev builds, plus some contrib modules published on various dates. > Does this issue reproduce without them - e.g. with clean user directory? I am not aware of any way to reproduce in a clean user directory.
(In reply to comment #27) > Sorry, which modules are you referring to? I always run with recent dev builds, > plus some contrib modules published on various dates. Those that print warnings into the log file about necessity to upgrade dependencies, using deprecated or ineffective APIs, etc.
Finally found the trigger condition. My $userdir/config/Modules/*.xml for OSGi bundles, dating from Nov 29 2011, include <param name="startlevel">4</param> If this is removed at least from org-eclipse-*.xml, the error disappears. Otherwise reproducible merely by starting IDE with a fresh cache dir.
Thanks a lot. So this error is not going to affect 7.2 and it will disappear as soon as we upgrade to new version of org.eclipse libraries (as they have never spec versions and the config/Modules/*.xml) will not contain any startlevel informaton (as that has been removed soon after 7.1, commit 3a32c36b3bda, bug 206468).
(In reply to comment #30) > it will disappear as soon as we upgrade to new version of org.eclipse libraries I do not think so. The NBM-installed ide/config/Modules/org-eclipse-*.xml already do not specify startlevel and are fine. The problem is with old $userdir/config/Modules/*.xml overrides, which AFAIK will continue to be loaded indefinitely regardless of library upgrades. You need to actively upgrade (or delete) the old userdir overrides.
(In reply to comment #31) > or delete ...which would be easier if we had implemented bug #213996, though too late for this issue. May or may not affect people using a new userdir and importing settings; will definitely affect people using the old userdir. Maybe best for ModuleList to simply check for *.xml mentioning startlevel with an old timestamp (?!).
Note that the affected config files are for bundles, which are all marked as autoloads, meaning that there is no reason for the userdir override to begin with; I am not sure why it was ever created, and it should be safe to delete. (i.e. FileObject.revert)
Adding warning into messages.log: ergonomics#e82a8bd96ae3
*** Bug 215389 has been marked as a duplicate of this bug. ***