Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 203790 - NullPointerException at
NullPointerException at
Product: platform
Classification: Unclassified
Component: Netigso
All All
: P2 (vote)
: 7.2
Assigned To: Jaroslav Tulach
: 202526 204740 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2011-10-17 01:48 UTC by Petr Cyhelsky
Modified: 2012-03-22 11:12 UTC (History)
14 users (show)

See Also:
Issue Type: DEFECT

stacktrace (1.65 KB, text/plain)
2011-10-17 01:48 UTC, Petr Cyhelsky
startlevel 4 for all our OSGi bundles, 3 for registry (24.84 KB, patch)
2011-11-09 16:40 UTC, Jaroslav Tulach
Details | Diff
stacktrace (1.65 KB, text/plain)
2012-02-23 00:11 UTC, Jesse Glick
stacktrace (1.65 KB, text/plain)
2012-02-27 17:38 UTC, Jesse Glick
stacktrace (1.65 KB, text/plain)
2012-03-21 09:46 UTC, J Bachorik

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Cyhelsky 2011-10-17 01:48:46 UTC
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

   at org.eclipse.osgi.framework.internal.core.BundleContextImpl$
   at org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop(
   at org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(
Comment 1 Petr Cyhelsky 2011-10-17 01:48:50 UTC
Created attachment 112106 [details]
Comment 2 Jesse Glick 2011-10-20 15:15:15 UTC
Happens every shutdown. Needs to be solved for 7.1 I think.
Comment 3 Jaroslav Tulach 2011-10-31 19:56:48 UTC
The problem is that 
called from BundleActivator.stop() is called sooner than

Can be workarounded by somebody calling while the system is running.
Comment 4 Tomas Stupka 2011-11-01 12:18:30 UTC
(In reply to comment #3)
> The problem is that 
> org.eclipse.core.internal.registry.RegistryProvider.releaseDefault
> called from BundleActivator.stop() is called sooner than
> Can be workarounded by somebody calling 
who would be that? 

> while the system is running.
would that be possible to access? is exported with x-internal:=true ...
Comment 5 Jaroslav Tulach 2011-11-02 20:12:39 UTC
The other solution could be to play with OSGi start levels. Make sure org.eclipse.core.internal.registry has lower level than
Comment 6 Jaroslav Tulach 2011-11-04 16:23:40 UTC
*** Bug 202526 has been marked as a duplicate of this bug. ***
Comment 7 Jaroslav Tulach 2011-11-07 10:10:51 UTC
*** Bug 204740 has been marked as a duplicate of this bug. ***
Comment 8 Jaroslav Tulach 2011-11-09 16:40:49 UTC
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.
Comment 9 Jaroslav Tulach 2011-11-09 16:41:40 UTC
The diff contains small API change documented in harness/README. Jesse, please approve.
Comment 10 Jesse Glick 2011-11-09 17:11:34 UTC
[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 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".
Comment 11 Jaroslav Tulach 2011-11-09 17:45:09 UTC
> [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.
Comment 12 Jesse Glick 2011-11-09 17:55:31 UTC
module.startlevel=4 in projectized.xml would suffice, I think.
Comment 13 Jaroslav Tulach 2011-11-10 09:28:01 UTC
Comment 14 Jaroslav Tulach 2011-11-23 06:25:58 UTC
Already propagated to main:
Comment 15 Jesse Glick 2012-01-27 21:49:44 UTC
This has regressed in dev builds.
Comment 16 Jaroslav Tulach 2012-02-04 17:00:32 UTC
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.
Comment 17 Jesse Glick 2012-02-23 00:11:01 UTC
Created attachment 116042 [details]
Comment 18 Exceptions Reporter 2012-02-23 00:11:15 UTC
This bug already has 10 duplicates 
Comment 19 Jaroslav Tulach 2012-02-24 13:40:34 UTC
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.
Comment 20 Jesse Glick 2012-02-27 17:38:13 UTC
By the way it seems that a bunch of reports attached to this bug are actually unrelated, such as exception #562500.
Comment 21 Jesse Glick 2012-02-27 17:38:44 UTC
Created attachment 116150 [details]

Trying to override an (empty) <folder> in favorites module with an (empty) <file> in projectui.
Comment 22 Jaroslav Tulach 2012-03-16 09:44:54 UTC
Update to 3.7.1 have not fixed anything. Reported as
Comment 23 Jaroslav Tulach 2012-03-16 12:42:11 UTC
Comment 24 J Bachorik 2012-03-21 09:46:13 UTC
Created attachment 116985 [details]

Switched project group before scanning has even started
Comment 25 Quality Engineering 2012-03-22 11:12:32 UTC
Integrated into 'main-golden', will be available in build *201203220400* on (upload may still be in progress)
User: Jaroslav Tulach <>
Log: #203790: Using JAR as attached to Eclipse bug 374466.

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo