I opened https://issues.apache.org/jira/browse/FELIX-3658 for the first problem and think I have a simple fix.
For the second problem, it looks like whenever you disable a component its component id is set to -1. So the problem must be something with re-enabling it. I haven't looked further. thanks! david jencks On Sep 6, 2012, at 1:22 PM, Pierre De Rop wrote: > Hi David, > > I don't know if it's related to the problem you are talking about, but I > just noticed a problem which might also be related to ServiceFactory. > > here it is: > > When you have a delayed component "A", which is activated because another > component "B" has a dependency on it (dynamic, cardinality=0..N), then when > you manually disable "A" (from the "scr:disable" shell commandl), you then > get an "java.lang.IllegalStateException: ungetServiceDisabled" error: > > g! scr:list > Id State Name > [ 2] [active ] test.disable.A > [ 0] [active ] test.disable.B > [ 1] [active ] test.disable.LogTracker > g! scr:disable 2 > Component test.disable.A disabled > g! ERROR: Bundle test.scr.deadlock2 [9] ServiceRegistrationImpl: Error > ungetting service. (java.lang.IllegalStateException: ungetServiceDisabled) > java.lang.IllegalStateException: ungetServiceDisabledLogTracker: L=INFO, > T=Thread[Thread-1,5,main], M=ServiceEvent UNREGISTERING > > at > org.apache.felix.scr.impl.manager.AbstractComponentManager$State.ungetService(AbstractComponentManager.java:1308) > at > org.apache.felix.scr.impl.manager.ImmediateComponentManager.ungetService(ImmediateComponentManager.java:693) > at > org.apache.felix.framework.ServiceRegistrationImpl.ungetFactoryUnchecked(ServiceRegistrationImpl.java:349) > at > org.apache.felix.framework.ServiceRegistrationImpl.ungetService(ServiceRegistrationImpl.java:258) > at > org.apache.felix.framework.ServiceRegistry.ungetService(ServiceRegistry.java:389) > at org.apache.felix.framework.Felix.ungetService(Felix.java:3432) > at > org.apache.felix.framework.BundleContextImpl.ungetService(BundleContextImpl.java:486) > at > org.apache.felix.scr.impl.manager.DependencyManager.ungetService(DependencyManager.java:913) > at > org.apache.felix.scr.impl.manager.DependencyManager.serviceRemoved(DependencyManager.java:480) > at > org.apache.felix.scr.impl.manager.DependencyManager.serviceChanged(DependencyManager.java:250) > at > org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932) > at > org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) > at > org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) > at > org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4260) > at org.apache.felix.framework.Felix.access$000(Felix.java:74) > at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390) > at > org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:148) > at > org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:759) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager$State.doDeactivate(AbstractComponentManager.java:1354) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager$Disabled.deactivate(AbstractComponentManager.java:1428) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:619) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager$2.run(AbstractComponentManager.java:419) > at > org.apache.felix.scr.impl.ComponentActorThread.run(ComponentActorThread.java:98) > at java.lang.Thread.run(Thread.java:662) > stop > > I also noticed that when you disable an immediate component, then we have > no exceptions, but under the shell, the component id is then set to "-1", > and you then can't re-enable it anymore, but this is another kind of > problem, I think. > > > Are we talking about the same kind of ServiceFactory problem or should I > create a separate jira issue ? > > regards; > /pierre > > > > On Thu, Sep 6, 2012 at 6:31 PM, David Jencks <[email protected]> wrote: > >> Looking forward to any review :-) >> >> I've found an additional problem with ServiceFactory components that I'm >> trying to fix.... >> >> david jencks >> >> On Sep 6, 2012, at 2:54 AM, Pierre De Rop wrote: >> >>> Hi David, >>> >>> I'm happy to see that the test helped, and it seems that fixing this >> issue was not an easy task, >>> congratulation ! >>> >>> For now, I can't reply to your question about the bind/unbind/updated >> method, because I have not yet fully reviewed your fix, but this is an >> excellent exercise for me and I will take time to understand the changes >> you made. >>> >>> So, from my side, I confirm, the testcase is now passing. >>> >>> However, I have a minor remark: the felix log level is now forced to >> debug: see systemProperty( "ds.loglevel" ).value( "debug" ) in the >> ComponentTestBase class), and I think that it might be better to run the >> concurrent test in warn level, as before, because debug logs might reduce >> the chances to reproduce any potential concurrency issues ... Anyway, I >> tried to run the testcase with ds.loglevel=warn, and it is also passing OK. >>> >>> So, now, I will run again my nightly integration tests, in order to do >> more validation. >>> >>> thanks again. >>> /pierre >>> >>> On Thu, Sep 6, 2012 at 12:23 AM, David Jencks <[email protected]> >> wrote: >>> I finally got everything to work :-) (see caveats in the bug report). >>> >>> The itest was extremely helpful :-) >>> >>> One of the changes I made that perhaps could use some review is that >> once the bind/unbind/updated methods are set, they are never cleared from >> the dependency manager. I don't think this is really a problem. Have I >> missed something? >>> >>> We talked a bit a while ago about sharing the bind/unbind/updated >> methods among dependency managers and trying to make them look up the >> methods only once. I've moved most of the dependencyManager state out of >> the dependency managers, so we might be able to move the rest of the state >> out and share the dependency managers among all the component managers for >> the same component. This might be better post 1.8 however. >>> >>> Please try out the changes and let me know if you find more problems! >>> >>> thanks >>> david jencks >>> >>> On Sep 2, 2012, at 11:02 PM, David Jencks wrote: >>> >>>> Excellent! >>>> >>>> I've been working on my idea how to fix this, but I'm still at the >> stage of getting the existing integration tests to pass. At least some >> stuff works :-) >>>> >>>> Looking forward to trying out your test case... >>>> >>>> david jencks >>>> >>>> On Sep 2, 2012, at 6:58 AM, Pierre De Rop wrote: >>>> >>>>> Hi, >>>>> >>>>> I committed in revision 1379968 a (candidate) integration test, which >> seems >>>>> to reproduce the problem. >>>>> Hope it will help. >>>>> >>>>> regards; >>>>> /pierre >>>>> >>>>> On Fri, Aug 31, 2012 at 2:08 PM, Pierre De Rop < >> [email protected]>wrote: >>>>> >>>>>> Hi Felix, >>>>>> >>>>>> ok, I will try to do it. >>>>>> >>>>>> regards; >>>>>> /pierre >>>>>> >>>>>> On Fri, Aug 31, 2012 at 1:58 PM, Felix Meschberger < >> [email protected]>wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Am 31.08.2012 um 02:20 schrieb Pierre De Rop: >>>>>>> >>>>>>>> Hi David, >>>>>>>> >>>>>>>> I have progressed and it seems that now I can reproduce the >> problem, >>>>>>> using >>>>>>>> a sample code. >>>>>>>> It's a sample inspired from the scenario that you suggested in your >>>>>>>> previous post, with A > B > C, and A > C ... >>>>>>>> >>>>>>>> I will create a jira issue and will attach the sample to it. >>>>>>> >>>>>>> Thanks alot. >>>>>>> >>>>>>> Would be great if we could integrate that sample as an integration >> test >>>>>>> case. >>>>>>> >>>>>>> Regards >>>>>>> Felix >>>>>>> >>>>>>>> ... >>>>>>> >>>>>> >>>>>> >>>> >>> >>> >> >>
