Bug 443761 - java.lang.NullPointerException: null values not allowed" at org.eclipse.core.internal.registry.ReferenceMap.put(ReferenceMap.java:351)
Summary: java.lang.NullPointerException: null values not allowed" at org.eclipse.core....
Status: RESOLVED WORKSFORME
Alias: None
Product: Equinox
Classification: Eclipse Project
Component: Components (show other bugs)
Version: 3.10.0 Luna   Edit
Hardware: PC Windows 7
: P3 normal with 2 votes (vote)
Target Milestone: ---   Edit
Assignee: equinox.components-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-10 16:18 EDT by Roman Mukhin CLA
Modified: 2015-06-24 08:23 EDT (History)
2 users (show)

See Also:


Attachments
Stacktrace "java.lang.NullPointerException: null values not allowed" (2.10 KB, application/octet-stream)
2014-09-10 16:18 EDT, Roman Mukhin CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Mukhin CLA 2014-09-10 16:18:33 EDT
Created attachment 246932 [details]
Stacktrace "java.lang.NullPointerException: null values not allowed"

I have got the follow problem, but a different exception: "java.lang.NullPointerException: null values not allowed" (see attachment). It happens when equinox tryed to resolve application class from extension point "org.eclipse.core.runtime.applications" with bundle-id that does not exist.
How it could happend? My research reveal, that it happens by 2nd start if we have replaced some plugins, that makes contributions.

Here are the steps to reproduce the problem:

	1. Given: newly installed RCP-Application (i.e Eclipse luna). That has not been lauched yet (does  not have configuration caches (see below) inside configuration folder.
	2. Run RCP-application once, then close it. Ensure we have got configuration caches.
	3. Replace plugin x.y.z_1.0.0.jar with a new version x.y.z_1.0.1.jar at the file system level (without eclipse update site mechanism). For reproducible result use plugin with extension point "org.eclipse.core.runtime.applications"
	4. Run RCP-application again.

Here is the information about platform caches:
OSGI platfrom cache:
configuration/org.eclipse.osgi  - framework.info.x - contains following information for each platform bundle
	• Physical bundle location  (i.e. file:plugins/x.y.z_1.0.1.jar)
	• Assigned bundle-id
	• <Other info>
As well as "next bundle-id", that is used as id for the next installed bundle

configuration/org.eclipse.core.runtime  - .contributors.x - contains following information for each plugin that makes a contribution with extension point:
	• Symbolic-bundle-name
	• Bundle-id
	• <Other info>

Why it happens? By the 2nd start Equinox find out that ..
	• … configuration already exist, compatible and load it.
	• … it has a new module x.y.z_1.0.1.jar to install as a bundles. Such new bundle got "next bundle-id" (stored in cached configuration). 
	• … module x.y.z_1.0.0.jar does not exist any more, then remove it from platform.
It does not recognize, that x.y.z_1.0.1.jar and x.y.z_1.0.0.jar are different versions of same bundle even though it is marked as singleton (in cache too)

As a result we have at platform the same bundle (symbolic-name x.y.z) but the different bundle-id for it.
	
	• Eclipse-RPC try to load contributor cache and resolve classes, but stored mapping "symbolic-name <-> bundle-id" does not valid any more for replaced bundles. So it cannot resolve it and it cause different problems.

We can start such application only with -clean (for osgi cache) and  -Dosgi.checkConfiguration=true (eclipse cache)

What must be done: 
Equinox at the loading time must recognize such situation and assign the existing bundle-id (according to symbolic-name) at least for singleton-plugin.

There was no such problem with the previous version of eclipse (Juno 3.8.x) .this
Comment 1 Thomas Watson CLA 2014-10-02 16:39:06 EDT
I'm not able to reproduce.  What should happen is that when the bundle is removed/discarded by the framework then we should be updating the timestamp of the module database which should make Platform.getStateTimeStamp() to return a new value from the last time the registry cache was saved.  When the registry starts back up it should detect the state timestamp has changed and toss the cache and reconstruct it with the current set of bundles.
Comment 2 Roman Mukhin CLA 2014-10-03 12:30:58 EDT
Hello,
The problem is that we roll out our application without eclipse update mechanism. The whole set of plugins is just replaced by the new versions all at once at the file system level (in plugins folder of our RPC application, deleted olds and copied over news), but configuration is stored at some other place (at user private folder) and is not deleted during roll out. By the next start of our RCP application from equinox point of view some new bundles has been added (they got new bundle IDs) and others removed (but later), but from eclipse side the symbolic name are still the same and it has a configuration and it tries to load cached configuration and resolve cached contributors (symbolic name => bundle ID). Here the point: symbolic name to bundle ID gives an ID of the removed bundle. That confuse the eclipse - plugin with symbolic name exist but with bundle-ID not.
It is easy to reproduce with the plugin which contains "org.eclipse.core.runtime.applications" extension point contribution. Step to reproduce: stop RCP application (eclipse), then just replace the plugin with a news version (bundle version must be incremented i.e. 1.0.1.0 => 1.0.2.0) (delete the old one). Start RCP application (eclipse) again. You should get NullPoihterException during startup.
Comment 3 Thomas Watson CLA 2014-10-03 13:32:20 EDT
Do you have the org.eclipse.osgi.compatibility.state bundle in your plugins folder?  That bundle is necessary to have the rest of the eclipse platform function properly in Luna.
Comment 4 Thomas Watson CLA 2014-11-11 11:26:20 EST
Closing as works for me.  I suspect you are missing the org.eclipse.osgi.compatibility.state fragment.
Comment 5 Thomas Watson CLA 2015-06-24 08:23:10 EDT
*** Bug 470882 has been marked as a duplicate of this bug. ***