Community
Participate
Working Groups
During testing with DS and CM I get the following exception. I will try this weekend to get steps to reproduce this behaviour. But it look like to be very tricky. !ENTRY org.eclipse.equinox.ds 4 0 2010-03-30 21:03:39.319 !MESSAGE [SCR] Exception while activating instance de.kue.sequence.messanger.Command@11756a4 of component !STACK 0 java.lang.ClassCircularityError: de/kue/msgbus/channel/IChannelService at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) at java.lang.Class.getDeclaredMethods(Class.java:1791) at org.eclipse.equinox.internal.ds.model.ServiceComponent.getMethod(ServiceComponent.java:102) at org.eclipse.equinox.internal.ds.model.ServiceComponent.activate(ServiceComponent.java:188) at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.activate(ServiceComponentProp.java:139) at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.build(ServiceComponentProp.java:329) at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponent(InstanceProcess.java:572) at org.eclipse.equinox.internal.ds.ServiceReg.getService(ServiceReg.java:53) at org.eclipse.osgi.internal.serviceregistry.ServiceUse$1.run(ServiceUse.java:120) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.internal.serviceregistry.ServiceUse.getService(ServiceUse.java:118) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:447) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getService(ServiceRegistry.java:430) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.getService(BundleContextImpl.java:667) at org.osgi.util.tracker.ServiceTracker.addingService(ServiceTracker.java:442) at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896) at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261) at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:233) at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:840) at org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:104) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:933) 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.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:756) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:711) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:130) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:206) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:507) at org.eclipse.equinox.internal.ds.InstanceProcess.registerService(InstanceProcess.java:488) at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponents(InstanceProcess.java:251) at org.eclipse.equinox.internal.ds.Resolver.buildNewlySatisfied(Resolver.java:429) at org.eclipse.equinox.internal.ds.Resolver.enableComponents(Resolver.java:211) at org.eclipse.equinox.internal.ds.SCRManager.startedBundle(SCRManager.java:641) at org.eclipse.equinox.internal.ds.SCRManager.bundleChanged(SCRManager.java:236) 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:1350) at org.eclipse.osgi.framework.internal.core.Framework.publishBundleEvent(Framework.java:1301) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:345) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:279) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:406) at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:265) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:106) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:453) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216) at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:393) at org.eclipse.osgi.internal.loader.SingleSourcePackage.loadClass(SingleSourcePackage.java:33) at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:457) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) at java.lang.Class.getDeclaredMethod(Class.java:1935) at org.eclipse.equinox.internal.ds.model.ComponentReference.getMethod(ComponentReference.java:96) at org.eclipse.equinox.internal.ds.model.ComponentReference.bind(ComponentReference.java:315) at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.bindReference(ServiceComponentProp.java:414) at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.bind(ServiceComponentProp.java:209) at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.build(ServiceComponentProp.java:327) at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponent(InstanceProcess.java:572) at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponents(InstanceProcess.java:189) at org.eclipse.equinox.internal.ds.Resolver.buildNewlySatisfied(Resolver.java:429) at org.eclipse.equinox.internal.ds.Resolver.enableComponents(Resolver.java:211) at org.eclipse.equinox.internal.ds.SCRManager.performWork(SCRManager.java:800) at org.eclipse.equinox.internal.ds.SCRManager$QueuedJob.dispatch(SCRManager.java:767) at org.eclipse.equinox.internal.ds.WorkThread.run(WorkThread.java:89) at org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor.run(Executor.java:70) !ENTRY org.eclipse.osgi 4 0 2010-03-30 21:03:39.323 !MESSAGE An unexpected runtime error has occurred. !STACK 0 org.osgi.service.component.ComponentException: [SCR] Exception while activating instance de.kue.sequence.messanger.Command@11756a4 of component MsgCommand at org.eclipse.equinox.internal.ds.model.ServiceComponent.activate(ServiceComponent.java:244) at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.activate(ServiceComponentProp.java:139) at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.build(ServiceComponentProp.java:329) at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponent(InstanceProcess.java:572) at org.eclipse.equinox.internal.ds.ServiceReg.getService(ServiceReg.java:53) at org.eclipse.osgi.internal.serviceregistry.ServiceUse$1.run(ServiceUse.java:120) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.internal.serviceregistry.ServiceUse.getService(ServiceUse.java:118) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:447) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getService(ServiceRegistry.java:430) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.getService(BundleContextImpl.java:667) at org.osgi.util.tracker.ServiceTracker.addingService(ServiceTracker.java:442) at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896) at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261) at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:233) at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:840) at org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:104) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:933) 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.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:756) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:711) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:130) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:206) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:507) at org.eclipse.equinox.internal.ds.InstanceProcess.registerService(InstanceProcess.java:488) at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponents(InstanceProcess.java:251) at org.eclipse.equinox.internal.ds.Resolver.buildNewlySatisfied(Resolver.java:429) at org.eclipse.equinox.internal.ds.Resolver.enableComponents(Resolver.java:211) at org.eclipse.equinox.internal.ds.SCRManager.startedBundle(SCRManager.java:641) at org.eclipse.equinox.internal.ds.SCRManager.bundleChanged(SCRManager.java:236) 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:1350) at org.eclipse.osgi.framework.internal.core.Framework.publishBundleEvent(Framework.java:1301) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:345) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:279) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:406) at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:265) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:106) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:453) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216) at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:393) at org.eclipse.osgi.internal.loader.SingleSourcePackage.loadClass(SingleSourcePackage.java:33) at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:457) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) at java.lang.Class.getDeclaredMethod(Class.java:1935) at org.eclipse.equinox.internal.ds.model.ComponentReference.getMethod(ComponentReference.java:96) at org.eclipse.equinox.internal.ds.model.ComponentReference.bind(ComponentReference.java:315) at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.bindReference(ServiceComponentProp.java:414) at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.bind(ServiceComponentProp.java:209) at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.build(ServiceComponentProp.java:327) at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponent(InstanceProcess.java:572) at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponents(InstanceProcess.java:189) at org.eclipse.equinox.internal.ds.Resolver.buildNewlySatisfied(Resolver.java:429) at org.eclipse.equinox.internal.ds.Resolver.enableComponents(Resolver.java:211) at org.eclipse.equinox.internal.ds.SCRManager.performWork(SCRManager.java:800) at org.eclipse.equinox.internal.ds.SCRManager$QueuedJob.dispatch(SCRManager.java:767) at org.eclipse.equinox.internal.ds.WorkThread.run(WorkThread.java:89) at org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor.run(Executor.java:70) Caused by: java.lang.ClassCircularityError: de/kue/msgbus/channel/IChannelService at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) at java.lang.Class.getDeclaredMethods(Class.java:1791) at org.eclipse.equinox.internal.ds.model.ServiceComponent.getMethod(ServiceComponent.java:102) at org.eclipse.equinox.internal.ds.model.ServiceComponent.activate(ServiceComponent.java:188) ... 65 more !ENTRY de.kue.sequence.messanger 4 0 2010-03-30 21:03:39.327 !MESSAGE !STACK 0 org.osgi.framework.ServiceException: Exception in org.eclipse.equinox.internal.ds.ServiceReg.getService() at org.eclipse.osgi.internal.serviceregistry.ServiceUse.getService(ServiceUse.java:130) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:447) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getService(ServiceRegistry.java:430) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.getService(BundleContextImpl.java:667) at org.osgi.util.tracker.ServiceTracker.addingService(ServiceTracker.java:442) at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896) at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261) at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:233) at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:840) at org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:104) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:933) 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.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:756) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:711) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:130) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:206) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:507) at org.eclipse.equinox.internal.ds.InstanceProcess.registerService(InstanceProcess.java:488) at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponents(InstanceProcess.java:251) at org.eclipse.equinox.internal.ds.Resolver.buildNewlySatisfied(Resolver.java:429) at org.eclipse.equinox.internal.ds.Resolver.enableComponents(Resolver.java:211) at org.eclipse.equinox.internal.ds.SCRManager.startedBundle(SCRManager.java:641) at org.eclipse.equinox.internal.ds.SCRManager.bundleChanged(SCRManager.java:236) 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:1350) at org.eclipse.osgi.framework.internal.core.Framework.publishBundleEvent(Framework.java:1301) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:345) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:279) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:406) at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:265) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:106) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:453) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216) at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:393) at org.eclipse.osgi.internal.loader.SingleSourcePackage.loadClass(SingleSourcePackage.java:33) at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:457) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) at java.lang.Class.getDeclaredMethod(Class.java:1935) at org.eclipse.equinox.internal.ds.model.ComponentReference.getMethod(ComponentReference.java:96) at org.eclipse.equinox.internal.ds.model.ComponentReference.bind(ComponentReference.java:315) at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.bindReference(ServiceComponentProp.java:414) at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.bind(ServiceComponentProp.java:209) at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.build(ServiceComponentProp.java:327) at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponent(InstanceProcess.java:572) at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponents(InstanceProcess.java:189) at org.eclipse.equinox.internal.ds.Resolver.buildNewlySatisfied(Resolver.java:429) at org.eclipse.equinox.internal.ds.Resolver.enableComponents(Resolver.java:211) at org.eclipse.equinox.internal.ds.SCRManager.performWork(SCRManager.java:800) at org.eclipse.equinox.internal.ds.SCRManager$QueuedJob.dispatch(SCRManager.java:767) at org.eclipse.equinox.internal.ds.WorkThread.run(WorkThread.java:89) at org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor.run(Executor.java:70) Caused by: org.osgi.service.component.ComponentException: [SCR] Exception while activating instance de.kue.sequence.messanger.Command@11756a4 of component MsgCommand at org.eclipse.equinox.internal.ds.model.ServiceComponent.activate(ServiceComponent.java:244) at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.activate(ServiceComponentProp.java:139) at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.build(ServiceComponentProp.java:329) at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponent(InstanceProcess.java:572) at org.eclipse.equinox.internal.ds.ServiceReg.getService(ServiceReg.java:53) at org.eclipse.osgi.internal.serviceregistry.ServiceUse$1.run(ServiceUse.java:120) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.internal.serviceregistry.ServiceUse.getService(ServiceUse.java:118) ... 58 more Caused by: java.lang.ClassCircularityError: de/kue/msgbus/channel/IChannelService at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) at java.lang.Class.getDeclaredMethods(Class.java:1791) at org.eclipse.equinox.internal.ds.model.ServiceComponent.getMethod(ServiceComponent.java:102) at org.eclipse.equinox.internal.ds.model.ServiceComponent.activate(ServiceComponent.java:188) ... 65 more
Created attachment 163758 [details] Example to reproduce the exception With the given projects you can reproduce the exception. The setup is like the one in Bug 308022. Bundle A: * a command component * a ServiceOne component implementing IService (enabled="true", immediate="false", not a factory) * the IService interface Bundle B: * a command component * a ServiceTwo component implementing IService from Bundle A (enabled="true", immediate="false", not a factory) * a ServiceThree component implementing IService from Bunlde B (enabled="true", immediate="false", not a factory) This setup is ok. The following changes will cause the exception: * adding a 0..n reference from the command in Bundle B to all components which provides an IService * even adding only the method private void foobar(IService service) to the command component of Bundle B cause the problem * adding only an import de.kue.osgi.scr3.a.IService or using IService in a method does not cause the exception. * if the IService appears in a method signature (even if it is a private method) the exception shows up.
Created attachment 165511 [details] example projects Is there any progress on this? I tried a lot of things. Sometimes I get the exception and there are other times, the same projects work fine. Now I have an example with a working launcher+configuration and a broken launcher+configuration. It looks like the main different between both are the oder in which the bundles are activated/started: Working: - DS-Bundle - A-Bundle (with the service interface) - B-Bundle (with a service implementing the service interface) - CM-Bundle Broken: - DS-Bundle - CM-Bundle - B-Bundle (with the service interface) - A-Bundle (with a service implementing the service interface) I have seen this oder in an other project coming from the config.ini (property osgi.bundles). I tried to force equinox to use a different order in my business bundles, but no success. I do not know, how and where this order is written in the config.ini. Next newbie question would be, has this order really an influence on loading the bundles or was it just luck. I added the log files in the zip.
(In reply to comment #2) Thanks for your detailed bug report Jens. I didn't have time yet to look in details at the problem you reported. But I will surely do it. The problem seems to happen when a lazy started bundle providing DS services is started by a classload trigger. Could you try as a work around to remove the lazy activation policy for the bundles involved? I think it would be sufficient to do this for the bundle providing the service interface.
Created attachment 166101 [details] proposed patch This patch is more like a workaround. It changes the order of the building of DS components giving a priority to the newly satisfied DS components. The problem disappears in this case. We need to do some more debugging here to see why exactly this circularity error is happening. I saw it is an old problem that should have been solved. I refer to bug#135885. Thomas, could you take a look at this bug?
I spent a long time trying to reproduce this and I have had no luck. It would be helpful to know what class is being defined at the following line when the circularity error is thrown org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:188) I have tried to simulate causing the class loader to re-enter the loading of the class IService within the same DS resolver thread but everything I try ends up short-circuiting the defining of the IService class again when we call findLoadedClass before defining the IService class again.
Stoyan: I removed all lazy loading stuff and everything works fine. Thanks for the workaround. Thomas: I have also spend a long time to reproduce the exception. After enabling lazy loading it has gone. It looks like to be depending on the osgi.bundles in conjunction with some unknown race conditions. If you need more traces, please let me know.
Created attachment 166143 [details] Log with extra System.out in DefaultClassLoader Hello Thomas, I change DefaultClassLoader like this public Class defineClass(String name, byte[] classbytes, ClasspathEntry classpathEntry, BundleEntry entry) { System.out.println("DefaultClassLoader.name:" + name); return defineClass(name, classbytes, 0, classbytes.length, classpathEntry.getDomain()); } The last output before the exception is: DefaultClassLoader.name:de.kue.osgi.scr3.b.ServiceTwo Please see the attachment for the foll log.
(In reply to comment #5) > I spent a long time trying to reproduce this and I have had no luck. There are some important things to setup in order to reproduce it: 1) Use DS from HEAD (or if using DS from 3.6M6 you have to include also equinox.log bundle) 2) DS and CM bundles must be started before the test bundles A and B 3) Bundles A and B must have value "false" in the Auto-Start column in the launch configuration.
I was able to reproduce the error. It is important to make sure that both bundles A and B are at the same start-level and lazily activated AND bundle B is installed before bundle A. There is nothing we can do at the class loader level to help fix this. The issue the following: 1) We have some component implementation class B from Bundle B which has a method that takes as a parameter class A (foo(A)). Class A is a trigger class which will cause the lazy activation of bundle A. 2) The DS runtime gets a LAZY_ACTIVATION event for bundle B first since it is the first installed. This causes it to activate any resolvable immediate components, one of which is the component with the implementation class B. So DS loads class B from Bundle B. Defining class B does not cause Class A to automatically be loaded yet. Since we only have a method that takes Class A as a parameter there is no need for the VM to load Class A yet. 3) DS runtime then calls classB.getDeclaredMethods to find the activate method for the component. This causes class A to be loaded with the initiating class loader as bundle B. 4) The loading of Class A causes the LAZY_ACTIVATION event for Bundle A to be fired. This causes the DS to resolve more components. It now detects another component from Bundle B with an immediate activation (ServiceThree) which also implements interface class A. This causes class A to be loaded again with Bundle B as the initiating class loader. I wonder if there is a way to prevent recursive activation of immediate components. In this case we are processing the LAZY_ACTIVATION event for Bundle A while activating a component from Bundle B, this causes us to reprocess the list of components defined in Bundle B in place and causes additional components to be processed from Bundle B. It would be could if we could delay the activation of the second component (ServiceThree) until after the activation of the first component B.
(In reply to comment #9) Tom, your analysis is correct. > I wonder if there is a way to prevent recursive activation of immediate > components. In this case we are processing the LAZY_ACTIVATION event for > Bundle A while activating a component from Bundle B, this causes us to > reprocess the list of components defined in Bundle B in place and causes > additional components to be processed from Bundle B. It would be could if we > could delay the activation of the second component (ServiceThree) until after > the activation of the first component B. I am not sure this would solve the problem. For instance, if the new DS components in the lazy starting bundle provide services and satisfy new components in other bundles, the new components may be activated and they may use the same class that triggered the lazy start of the bundle. This is something SCR cannot predict. The only way that would really solve the class circularity error would be to split the processing of the lazy activated bundle to be performed asynchronously (now they are processed synchronously with the receiving of the LAZY_ACTIVATION event). This has one disadvantage though - it is not guaranteed that after the bundle is started its DS components will be processed. And there is no way to find out when the processing of the components has finished. We have had several people complaining about that. Now it is quite late to change the behavior of SCR like this. But this is still an option if it is configurable by a system property and/or trace option.
(In reply to comment #10) > The only way that would really solve the class circularity error would be to > split the processing of the lazy activated bundle to be performed > asynchronously (now they are processed synchronously with the receiving of the > LAZY_ACTIVATION event). This has one disadvantage though - it is not guaranteed > that after the bundle is started its DS components will be processed. And there > is no way to find out when the processing of the components has finished. We > have had several people complaining about that. Now it is quite late to change > the behavior of SCR like this. But this is still an option if it is > configurable by a system property and/or trace option. I agree that re-ordering activation will not solve all problems but it probably will help in many cases. I think this is along the lines of your possible workaround fix. I completely agree with you on the danger of changing the behavior to asynchronous at this point in the release. You could look into an optional setting, but I am almost certain that enabling that setting will break much of our usage of DS in Eclipse and p2.
(In reply to comment #11) > I agree that re-ordering activation will not solve all problems but it probably > will help in many cases. I think this is along the lines of your possible > workaround fix. Yes, the patch is doing that. We should release it for RC1.
(In reply to comment #12) > Yes, the patch is doing that. We should release it for RC1. Marking for RC1, I will do a review of the patch.
(In reply to comment #4) > Created an attachment (id=166101) [details] > proposed patch > > This patch is more like a workaround. > It changes the order of the building of DS components giving a priority to the > newly satisfied DS components. The problem disappears in this case. > We need to do some more debugging here to see why exactly this circularity > error is happening. I saw it is an old problem that should have been solved. I > refer to bug#135885. > > Thomas, could you take a look at this bug? I think the new behavior is better. It marks the list of components to build as as STATE_ACTIVATING in one pass and then proceeds to build them in another pass. This allows for the STATE_ACTIVATING components from the original list of components to be activated to be excluded from the list of newly satisfied components that may result from building one of the components from the original list. As Stoyan states, this essentially gives priority to the newly satisfied DS components over the remaining components from original list of components. For many cases this will help prevent the Circular loading error we saw in this bug. There may be some cases where we will still see the error, see Stoyan's comment 10. I have not proven that a scenario like that would cause the error, but it looks like something like that could cause the error even with the fix. But I do have some questions about the fix. - Should all calls to InstanceProcess.getLock() be protected by a finally{InstanceProcess.freeLock()} ? If any unexpected exception is thrown then it seems like the lock would never be freed in some cases in the InstanceProcess. - I don't understand the logic for Resolver.reorderSCP(ServiceComponentProp). Is that a last resort to try and put the component at the end of the list to enable if some error occurs while building a component? If an error keeps happening then could we get in an endless loop? In my environment to reproduce this bug the Resolver.reorderSCP(ServiceComponentProp) method was never called. Is this part of the fix needed, and is it safe to do?
(In reply to comment #14) > But I do have some questions about the fix. > > - Should all calls to InstanceProcess.getLock() be protected by a > finally{InstanceProcess.freeLock()} ? If any unexpected exception is thrown > then it seems like the lock would never be freed in some cases in the > InstanceProcess. Yes. getLock() must have an appropriate call of freeLock(). I rechecked the code of InstanceProcess where these methods are used and I didn't find places where freeLock() could be missed after a getLock(). Most of the places are protected with finally block as you suggested. There are few places where try/finally was not used. But I consider these places to be safe and no unexpected exceptions are thrown. Of course I could add try/finally to add extra protection but I consider this measure unnecessary. > > - I don't understand the logic for Resolver.reorderSCP(ServiceComponentProp). > Is that a last resort to try and put the component at the end of the list to > enable if some error occurs while building a component? If an error keeps > happening then could we get in an endless loop? In my environment to reproduce > this bug the Resolver.reorderSCP(ServiceComponentProp) method was never called. > Is this part of the fix needed, and is it safe to do? This is not exactly part of this fix. The meaning of Resolver.reorderSCP() is to place the component that failed to activate at the end of the component list, so on the next build pass this component will be the last to activate. This sometimes may solve problems that occur due to some group of components may depend on their order of activation. This bug is actually a private similar case. If the error keeps happening we will not have an endless loop. Placing the component at last position does not mean that it will be processed once again in the current build pass. The component build process is provoked by a service event.
I released the patch. Thanks Jens for helping us track down this rather thorny issue. Thanks Stoyan for investigating a work around. Please open up a separate bug if you have a different scenario that causes a new circularity error.
