Community
Participate
Working Groups
Build Identifier: 20110301-1815 I have an OSGi bundle which uses the OSGi component factory as in the following example: "Using the Component Factory service" on http://dz.prosyst.com/pdoc/mbs_prof_6.1/um/framework/bundles/osgi/scr/scr.html#factory Binding and service creation works fine but during service unbinding I'm getting a NPE: !SESSION 2011-05-03 10:21:50.920 ----------------------------------------------- eclipse.buildId=unknown java.version=1.6.0_21 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en Framework arguments: -version 3 -port 65007 -testLoaderClass org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestLoader -loaderpluginname org.eclipse.jdt.junit.runtime -test com.vipera.osgi.system.test.SystemTestCase:testPersistenceService -application org.eclipse.pde.junit.runtime.coretestapplication -testpluginname com.vipera.osgi.system.test Command-line arguments: -os win32 -ws win32 -arch x86_64 -consoleLog -version 3 -port 65007 -testLoaderClass org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestLoader -loaderpluginname org.eclipse.jdt.junit.runtime -test com.vipera.osgi.system.test.SystemTestCase:testPersistenceService -application org.eclipse.pde.junit.runtime.coretestapplication -data C:\dev\ws\eclipse\osgi/../junit-workspace -dev file:C:/dev/ws/eclipse/osgi/.metadata/.plugins/org.eclipse.pde.core/pde-junit/dev.properties -os win32 -ws win32 -arch x86_64 -consoleLog -testpluginname com.vipera.osgi.system.test !ENTRY org.eclipse.equinox.ds 4 0 2011-05-03 10:21:54.989 !MESSAGE Exception while disposing instances of component ServiceComponentProp[ name = com.vipera.osgi.core.persistence state = Unsatisfied properties = {component.name=com.vipera.osgi.core.persistence, component.id=6, objectClass=String[com.vipera.osgi.core.persistence.IPersistenceService]}] !STACK 0 java.lang.NullPointerException at org.eclipse.equinox.internal.ds.impl.ComponentInstanceImpl.freeServiceReferences(ComponentInstanceImpl.java:85) at org.eclipse.equinox.internal.ds.impl.ComponentInstanceImpl.dispose(ComponentInstanceImpl.java:72) at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.dispose(ServiceComponentProp.java:103) at org.eclipse.equinox.internal.ds.InstanceProcess.disposeInstances(InstanceProcess.java:365) at org.eclipse.equinox.internal.ds.InstanceProcess.disposeInstances(InstanceProcess.java:305) at org.eclipse.equinox.internal.ds.Resolver.disposeComponentConfigs(Resolver.java:685) at org.eclipse.equinox.internal.ds.Resolver.disableComponents(Resolver.java:661) at org.eclipse.equinox.internal.ds.SCRManager.stoppingBundle(SCRManager.java:553) at org.eclipse.equinox.internal.ds.SCRManager.bundleChanged(SCRManager.java:232) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:919) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:227) at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:149) at org.eclipse.osgi.framework.internal.core.Framework.publishBundleEventPrivileged(Framework.java:1349) at org.eclipse.osgi.framework.internal.core.Framework.publishBundleEvent(Framework.java:1300) at org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(BundleHost.java:497) at org.eclipse.osgi.framework.internal.core.AbstractBundle.suspend(AbstractBundle.java:550) at org.eclipse.osgi.framework.internal.core.Framework.suspendBundle(Framework.java:1097) at org.eclipse.osgi.framework.internal.core.StartLevelManager.decFWSL(StartLevelManager.java:597) at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:257) at org.eclipse.osgi.framework.internal.core.StartLevelManager.shutdown(StartLevelManager.java:215) at org.eclipse.osgi.framework.internal.core.InternalSystemBundle.suspend(InternalSystemBundle.java:266) at org.eclipse.osgi.framework.internal.core.Framework.shutdown(Framework.java:690) at org.eclipse.osgi.framework.internal.core.Framework.close(Framework.java:588) at org.eclipse.core.runtime.adaptor.EclipseStarter.shutdown(EclipseStarter.java:415) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:198) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:620) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:575) at org.eclipse.equinox.launcher.Main.run(Main.java:1408) at org.eclipse.equinox.launcher.Main.main(Main.java:1384) Reproducible: Always Steps to Reproduce: 1. Develop a simple service using the OSGi ComponentFactory framework 2. Start the service and let a client resolve it 3. Unbind and terminate the service -> NPE
I could not reproduce this problem as described. I have spent some time to analyze the code and trying to reproduce. I agree this exception can happen but in very specific, hard to reproduce, situations: - when due to circularity a service object cannot be get - if BundleContext.getService() returns null (there can be many reasons) I will apply a fix which is pretty safe and obvious. But I cannot test and confirm if it really fix the problem you experienced. If you have any project/s that reproduce the problem please attach them to the bug.
Created attachment 198974 [details] proposed patch
Created attachment 202076 [details] Sample project reproducing the issue I have this problem too, it occurs when I dispose ComponentInstance which has references to other services. See attached sample project (with launcher).
Someone asked about this bug on IRC. M3 is this week so I presume this will be delayed to M4?
Moving to M4. I don't think Stoyan is available until November to fix this.
Thanks for the sample project Ivan! I was able to reproduce. The problem appears when the component provided by ComponentFactory has a reference and does not specify unbind method for that reference. The patch that I have already provided fixes this bug. I have released it to upstream.
