Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 363797 - NullPointerException in CompositeConfigurator.createClassLoader
Summary: NullPointerException in CompositeConfigurator.createClassLoader
Status: RESOLVED FIXED
Alias: None
Product: Equinox
Classification: Eclipse Project
Component: Framework (show other bugs)
Version: 3.6.2   Edit
Hardware: PC All
: P3 normal (vote)
Target Milestone: 3.6.2+   Edit
Assignee: Thomas Watson CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 363561
Blocks:
  Show dependency tree
 
Reported: 2011-11-15 06:04 EST by Thomas Watson CLA
Modified: 2011-11-15 16:11 EST (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Watson CLA 2011-11-15 06:04:29 EST 
Cloning bug to release to 3.6.2+ and 3.7.2.

+++ This bug was initially created as a clone of Bug #363561 +++

Build Identifier: Equinox 3.6.2

Sometimes stopping a Composite can yield an NPE of the form, 
Caused by: java.lang.NullPointerException
        at org.eclipse.osgi.internal.composite.CompositeConfigurator.createClassLoader(CompositeConfigurator.java:174)
        at org.eclipse.osgi.baseadaptor.BaseData.createClassLoader(BaseData.java:94)
        at org.eclipse.osgi.internal.loader.BundleLoader.createBCL(BundleLoader.java:842)
        at org.eclipse.osgi.internal.loader.BundleLoader.createBCLPrevileged(BundleLoader.java:831)
        at org.eclipse.osgi.internal.loader.BundleLoader.createClassLoader(BundleLoader.java:377)
        at org.eclipse.osgi.internal.composite.CompositeImpl.checkClassLoader(CompositeImpl.java:158)
        at org.eclipse.osgi.internal.composite.CompositeImpl.uninstall(CompositeImpl.java:148)
        at org.apache.aries.application.runtime.framework.BundleFrameworkImpl.close(BundleFrameworkImpl.java:99)

Tom Watson writes, "Binding the lifecycle of the composite framework to the start/stop lifecycle of the composite causes very bad things to happen when performing operations on a stopped composite.  This is because we have obliterated the composite framework and have to init a new one when trying to do anything with the composite."

Tom provided a successful patch for this issue, saying "I have tried to insert a small bit of code for when a composite is started to allow its class loader to get created successfully so that if/when the composite is uninstalled we will not have to create the class loader which points to a dead framework."

Reproducible: Sometimes

Steps to Reproduce:
Reproducible test case provided directly to Tom Watson.