Bugzilla – Full Text Bug Listing
| Summary: | NullPointerException in CompositeConfigurator.createClassLoader | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Mark Nuttall <mnuttall> |
| Component: | Framework | Assignee: | Thomas Watson <tjwatson> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | tjwatson |
| Version: | unspecified | ||
| Target Milestone: | Juno M4 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 363797 | ||
A few scenarios can cause this with the following conditions: - A composite which exports packages must be involved. - The class loader for the composite must not have already been created before composite uninstall. - A constituent bundle in the composite must be uninstalled which provides the actual content for the exported package from the composite before the composite is uninstalled. It is unclear to me why the constituent bundles are uninstalled before you uninstall the composite since unintalling the composite should clean up the constituents automatically. At any rate, we should not be failing like this. Unfortunately a proper fix for this is likely to take a large amount of effort. The original composite design is fatally flawed because we tie the composite framework directly to the start/stop operations of the composite bundle. So when a composite is stopped the innards of the composite framework are destroyed and we are left in a bad state. Even though the composite bundle is resolved it lacks a functioning composite framework to allow any of its content to be accessed in a reasonable way. So we have two options: 1) Try to do a proper fix which does not leave the composite framework in this awkward state on composite stop. This is difficult to do since the current behavior is also desired in other cases where we want to clean up all the resources of the composite framework on composite stop (listeners, threads, events etc.). I am not inclined to do this at the moment since the current composite framework support is simply a prototype for a draft OSGi specification that ultimately got killed. 2) Another option is to initialize the composite classloader for composites that export packages at composite start. This works around the current issue, but there are still cases where a stopped composite could give you trouble. I hope that we can provide a good migration path forward and get projects to use the OSGi EEG subsystems specification in the future. The subsystems specification provides a much more clean environment since we are not trying to deal with interactions between distinct "real" OSGi frameworks for each composite/application/feature installed. This will provide a much cleaner runtime to manage and debug IMO. |
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.