ops4j/peaberry

NPE stopping bundle that had issues starting

mcculls opened this issue · 1 comments

Originally reported on Google Code with ID 62

Here is the exception I got when trying to stop a bundle after it got in Issue 60:

java.lang.NullPointerException
    at org.ops4j.peaberry.activation.internal.ExportBundleRoot.deactivate(ExportBundleRoot.java:35)
    at org.ops4j.peaberry.activation.internal.ExportBundleRoot.deactivate(ExportBundleRoot.java:22)
    at org.ops4j.peaberry.activation.internal.InstanceBundleRoot.deactivate(InstanceBundleRoot.java:51)
    at org.ops4j.peaberry.activation.internal.BundleActivation.deactivate(BundleActivation.java:194)
    at org.ops4j.peaberry.activation.internal.BundleActivation.update(BundleActivation.java:153)
    at org.ops4j.peaberry.activation.internal.StateBundleActivationTracker.stop(StateBundleActivationTracker.java:45)
    at org.ops4j.peaberry.activation.internal.BundleActivation.stop(BundleActivation.java:142)
    at org.ops4j.peaberry.activation.internal.BundleTracker.stop(BundleTracker.java:112)
    at org.ops4j.peaberry.activation.internal.BundleTracker.bundleChanged(BundleTracker.java:86)
    at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:807)
    [Gogo shell] DEBUG com.frevvo.pellet.data.gae - ServiceEvent UNREGISTERING

Maybe it got into a bad state after the first exception (Issue 60), but in any case,
it should be a no brainer to avoid this NPE.

Reported by ydewit on 2011-04-16 01:17:45

Fixed the issue. Now when the startup of the initial singletons fails we stop all singletons
that were started before the failure occurred.

Reported by Rinsvind on 2011-05-07 18:44:04

  • Status changed: Fixed