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 201110160600) VM: Java HotSpot(TM) Client VM, 21.0-b17, Java(TM) SE Runtime Environment, 1.7.0-b147 OS: Windows 7 User Comments: MackSix: I shut down netbeans and restarted it and this happened. GUEST: i just used the auto apdater Stacktrace: java.lang.NullPointerException at org.eclipse.equinox.internal.security.storage.PasswordProviderSelector.getInstance(PasswordProviderSelector.java:67) at org.eclipse.equinox.internal.security.auth.AuthPlugin.stop(AuthPlugin.java:73) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:843) at java.security.AccessController.doPrivileged(AccessController.java:0) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop(BundleContextImpl.java:836) at org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(BundleHost.java:501)
Created attachment 112106 [details] stacktrace
Happens every shutdown. Needs to be solved for 7.1 I think.
The problem is that org.eclipse.core.internal.registry.RegistryProvider.releaseDefault called from BundleActivator.stop() is called sooner than org.eclipse.equinox.internal.security.auth.AuthPlugin.stop() Can be workarounded by somebody calling org.eclipse.equinox.internal.security.storage.PasswordProviderSelector.getInstances() while the system is running.
(In reply to comment #3) > The problem is that > org.eclipse.core.internal.registry.RegistryProvider.releaseDefault > called from BundleActivator.stop() is called sooner than > org.eclipse.equinox.internal.security.auth.AuthPlugin.stop() > > Can be workarounded by somebody calling who would be that? > org.eclipse.equinox.internal.security.storage.PasswordProviderSelector.getInstances() > while the system is running. would that be possible to access? org.eclipse.equinox.internal.security.storage is exported with x-internal:=true ...
The other solution could be to play with OSGi start levels. Make sure org.eclipse.core.internal.registry has lower level than org.eclipse.equinox.internal.security.auth.
*** Bug 202526 has been marked as a duplicate of this bug. ***
*** Bug 204740 has been marked as a duplicate of this bug. ***
Created attachment 113054 [details] startlevel 4 for all our OSGi bundles, 3 for registry Registry needs to be initialized sooner than other bundles and shut down later. In OSGi world this cannot be achieved with mutual dependencies, but rather by assigning different start levels.
The diff contains small API change documented in harness/README. Jesse, please approve.
[JG01] $level.length() == 0 :: $level instanceof java.lang.String => $level.isEmpty();; [JG02] Why do we need to specify module.startlevel=4 for every OSGi bundle in NB? Why is the default not good enough for them, just overriding it for one or both of the two bundles mentioned in this bug report? If it is because the default is 1 and we cannot use 0 for o.eclipse.equinox.registry for some reason, can we use 2 (or higher) for just o.eclipse.equinox.security? Or set an IDE-wide default of 4 using branding (IIRC there was some other API change for this recently)? [JG03] "#NOI18N" may not be written "# NOI18N".
> [JG02] Most bundles in Eclipse run with startlevel 4. Now, when it is clear we cannot deal without startlevel, I thought that keeping things consistent with Eclipse is beneficial. I could possibly change projectized.xml to use module.startlevel=4 by default, so we don't need to override it in all our bundle wrapping modules.
module.startlevel=4 in projectized.xml would suffice, I think.
ergonomics#5e746d10e540
Already propagated to main: http://hg.netbeans.org/main-golden/rev/5e746d10e540
This has regressed in dev builds.
It regressed because I removed usage of startlevels. According to OSGi experts, the shutdown order is opposite to start order and in LazyActivation mode, the order should follow the usage of classes/singletons. So the behavior should be OK without startlevels. Probably Equinox 3.5 is broken. Update to Equinox 3.7.1 seems to fix this problem.
Created attachment 116042 [details] stacktrace
This bug already has 10 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=181345
Dependency on bug 207199 is probably not correct. This issue is random, sometimes NPE is thrown, sometimes not. Probably depends on who resolves the bundle and activates it. Maybe usage of transitive dependency would help then.
By the way it seems that a bunch of reports attached to this bug are actually unrelated, such as exception #562500.
Created attachment 116150 [details] stacktrace Trying to override an (empty) <folder> in favorites module with an (empty) <file> in projectui.
Update to 3.7.1 have not fixed anything. Reported as https://bugs.eclipse.org/bugs/show_bug.cgi?id=374466
ergonomics#43e569f109ec
Created attachment 116985 [details] stacktrace Switched project group before scanning has even started
Integrated into 'main-golden', will be available in build *201203220400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/43e569f109ec User: Jaroslav Tulach <jtulach@netbeans.org> Log: #203790: Using JAR as attached to Eclipse bug 374466. URL: https://bugs.eclipse.org/bugs/attachment.cgi?id=212784 URL: https://bugs.eclipse.org/bugs/show_bug.cgi?id=374466