Hello David, Congratulations: no more "timeount on latch" errors, our application is now starting seamlessly, and tests are all passing OK:
Results : Tests run: 104, Failures: 0, Errors: 0, Skipped: 0 +1 ! /Pierre On Wed, Oct 30, 2013 at 10:01 AM, David Jencks <[email protected]>wrote: > Hi Pierre, > > I think I see what's going on and I wrote a test case for my theory and > fixed it. Can you try again? > > many thanks! > david jencks > > On Oct 29, 2013, at 4:00 PM, Pierre De Rop <[email protected]> wrote: > > > Hi David, > > > > no, I did not notice the ERROR message you are mentioning. > > (see the full logs in stacktrace2.log which I juste attached in the > issue). > > > > Please forget my comment about the thread dump in WARN. I did not realize > > that it was intentional to log it in DEBUG. > > > > regards; > > /Pierre > > > > > > On Tue, Oct 29, 2013 at 6:40 PM, David Jencks <[email protected] > >wrote: > > > >> HI Pierre, > >> > >> Do you by any chance see a log message at ERROR level like > >> > >> Cannot create component instance due to failure to bind reference {0} > >> > >> shortly before the timeout message? > >> > >> I'm not sure if it's a good idea to dump the threads at WARN. If you > >> think it is I'll change it. Some people get upset if the logs are too > long > >> :-) > >> > >> thanks > >> david jencks > >> > >> > >> On Oct 29, 2013, at 8:46 AM, Pierre De Rop <[email protected]> > wrote: > >> > >>> yes David, consistently. but I don't see stacktraces. > >>> > >>> Now, looking at the code, I see that this stacktrace is logged in > DEBUG: > >>> > >>> final void dumpThreads() > >>> { > >>> try > >>> { > >>> String dump = new ThreadDump().call(); > >>> log( LogService.LOG_DEBUG, dump, null ); > >>> > >>> So, I will activate DEBUG and provide the stacktrace. > >>> > >>> But is this a bug to log this stacktrace in DEBUG ? > >>> I mean: should it be logged in WARN, instead of DEBUG ? > >>> > >>> /pierre > >>> > >>> > >>> On Tue, Oct 29, 2013 at 4:28 PM, David Jencks <[email protected] > >>> wrote: > >>> > >>>> Hi Pierre, > >>>> > >>>> I think there should be a thread dump in the log to go with this > >> message. > >>>> If there is could you send it to me or attach it to FELIX-4297? > >>>> > >>>> Does this happen consistently? > >>>> > >>>> many thanks > >>>> david jencks > >>>> > >>>> On Oct 29, 2013, at 3:43 AM, Pierre De Rop <[email protected]> > >> wrote: > >>>> > >>>>> Hi David; > >>>>> > >>>>> 1) Every integration tests are passing OK. > >>>>> > >>>>> Regarding the OOM, I believe that the out of memory is likely to be > >> cause > >>>>> by the following load tests, which are running in DEBUG mode: > >>>>> > >>>>> > >>>> > >> > src/test/java/org/apache/felix/scr/integration/ComponentConcurrencyTest.java > >>>>> src/test/java/org/apache/felix/scr/integration/Felix3680Test.java > >>>>> src/test/java/org/apache/felix/scr/integration/Felix3680_2Test.java > >>>>> > >>>>> > >>>>> So, I just added this in each files (in static initializers): > >>>>> > >>>>> DS_LOGLEVEL = "warn"; > >>>>> > >>>>> And I have no more OOM, with this nice test result message: > >>>>> > >>>>> Tests run: 103, Failures: 0, Errors: 0, Skipped: 0 > >>>>> [INFO] BUILD SUCCESS > >>>>> > >>>>> > >>>>> > >>>>> 2) Now, I did again a non regression tests with our applications, and > >> I'm > >>>>> seeing a new WARN message (but it does not seem to prevent the > >>>> application > >>>>> to be correctly initialized: all components are in the end > satisfied): > >>>>> > >>>>> (if you believe that it's now time to release, then you can go ahead, > >> and > >>>>> we'll then investigate this new issue after the release ... I let you > >>>>> decide) > >>>>> > >>>>> -> > >>>>> > >>>>> 2013-10-29 11:10:02,487 CM Event Dispatcher (Fire ConfigurationEvent: > >>>>> pid=com.alcatel.as.ioh.impl.server.ServerFactoryImpl) ERROR osgi - > >>>>> [com.alcatel.as.ioh.impl.server.ServerFactoryImpl(91)] > >> DependencyManager > >>>> : > >>>>> invokeBindMethod : timeout on open latch newtcpprocessor > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> kind regards; > >>>>> /Pierre > >>>>> > >>>>> > >>>>> On Tue, Oct 29, 2013 at 12:13 AM, David Jencks < > [email protected] > >>>>> wrote: > >>>>> > >>>>>> Pierre, > >>>>>> > >>>>>> I opened https://issues.apache.org/jira/browse/FELIX-4297 and fixed > >> the > >>>>>> problems I found (for 2). I don't see the OOM often enough to have > >> any > >>>>>> confidence that anything I do would actually fix it, so I'm inclined > >> to > >>>> do > >>>>>> nothing. Is that OK with you? > >>>>>> > >>>>>> Unless you can find some more problems :-) I'm planning to try > >> another > >>>>>> release when the config admin 1.8 gets to maven central. I'm going > to > >>>>>> update the pom to normally run against the CA 1.8 version supporting > >> R5 > >>>> and > >>>>>> change the profile so running against R4 requires specifying > profiles > >>>>>> explicitly. > >>>>>> > >>>>>> thanks again! > >>>>>> david jencks > >>>>>> > >>>>>> On Oct 28, 2013, at 12:24 AM, David Jencks <[email protected]> > >>>> wrote: > >>>>>> > >>>>>>> Hi Pierre, > >>>>>>> > >>>>>>> Much better to find these problems before a release than just > after! > >>>>>>> > >>>>>>> I saw an OOM once recently but haven't been able to reproduce it. > >>>>>>> > >>>>>>> I'm looking into the NPE. I think I see the timing hole it is > using > >>>> but > >>>>>> need to think about it some more. > >>>>>>> > >>>>>>> many thanks! > >>>>>>> david jencks > >>>>>>> > >>>>>>> On Oct 27, 2013, at 2:58 AM, Pierre De Rop <[email protected] > > > >>>>>> wrote: > >>>>>>> > >>>>>>>> Hi David, > >>>>>>>> > >>>>>>>> Looking at our configurator component we are currently using (but > we > >>>>>> will fix it in order to use the multi-location "?"), I see this: > >>>>>>>> > >>>>>>>> void configure(String pid, Dictionary pidConf) { > >>>>>>>> Configuration config = getConfiguration(_pid, null); > >>>>>>>> if (config.getBundleLocation() != null) { > >>>>>>>> config.setBundleLocation(null); > >>>>>>>> } > >>>>>>>> config.update(pidConf); > >>>>>>>> } > >>>>>>>> > >>>>>>>> So I believe that you are getting a null configuration because > there > >>>> is > >>>>>> a short window between the setBundleLocation(null) (at this point, > the > >>>>>> configuration is null) and the config.update(pidConf) call ... > >>>>>>>> > >>>>>>>> So, the good news is that I'm not having anymore some NPE using > your > >>>>>> latest commits :-) and I think our application is now fully > >> operational. > >>>>>>>> > >>>>>>>> but ... (please don't start to abominate me ) now, in order to > do a > >>>>>> final check, I restarted the integration tests and there is still > two > >>>>>> problems: > >>>>>>>> > >>>>>>>> 1) I'm sometimes getting some out of memory errors: this is > probably > >>>>>> caused by the ComponentConcurrencyTest/Felix3680Test tests, which > are > >>>>>> currently configured in DEBUG mode ? > >>>>>>>> > >>>>>>>> 2) I ran the tests two times, and the second time, I got this > >>>> exception > >>>>>> with the failing > >>>>>>>> Felix3680_2Test: > >>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >> > test_concurrent_injection_with_bundleContext(org.apache.felix.scr.integration.Felix3680_2Test) > >>>>>> Time elapsed: 36.597 sec <<< ERROR! > >>>>>>>> java.lang.NullPointerException > >>>>>>>> at > >>>>>> > >>>> > >> > org.apache.felix.scr.impl.manager.DependencyManager.invokeUnbindMethod(DependencyManager.java:1710) > >>>>>>>> at > >>>>>> > >>>> > >> > org.apache.felix.scr.impl.manager.SingleComponentManager.invokeUnbindMethod(SingleComponentManager.java:387) > >>>>>>>> at > >>>>>> > >>>> > >> > org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:355) > >>>>>>>> at > >>>>>> > >>>> > >> > org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:290) > >>>>>>>> at > >>>>>> > >>>> > >> > org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1503) > >>>>>>>> at > >>>>>> > >>>> > >> > org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1398) > >>>>>>>> at > >>>>>> > >>>> > >> > org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.untrack(ServiceTracker.java:1258) > >>>>>>>> at > >>>>>> > >>>> > >> > org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1437) > >>>>>>>> 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.integration.components.felix3680_2.Main$RegistrationHelper$2.run(Main.java:136) > >>>>>>>> at > >>>>>> > >>>> > >> > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > >>>>>>>> at > >>>>>> > >>>> > >> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > >>>>>>>> at java.lang.Thread.run(Thread.java:722) > >>>>>>>> > >>>>>>>> Are you also getting this exception ? > >>>>>>>> > >>>>>>>> thanks > >>>>>>>> > >>>>>>>> /Pierre > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On Sat, Oct 26, 2013 at 6:34 PM, David Jencks < > >> [email protected] > >>>>> > >>>>>> wrote: > >>>>>>>> Hi PIerre, > >>>>>>>> > >>>>>>>> Looking at the CA spec it looks like CA is supposed to send out > >>>>>> CM_LOCATION_CHANGED events even before any properties are set when > >>>>>> setBundleLocation is called. I added some code to ignore these > >> events. > >>>>>> Note that DS is "reserving" the configurations for (one of) the > >>>>>> component(s) that will be consuming them by calling > >>>> getConfiguration(pid). > >>>>>>>> > >>>>>>>> I do wonder how the location to something non-null on your > >>>>>> configurations before the properties are set. > >>>>>>>> > >>>>>>>> Waiting for the next bug :-) > >>>>>>>> > >>>>>>>> thanks > >>>>>>>> david jencks > >>>>>>>> > >>>>>>>> On Oct 26, 2013, at 3:00 AM, Pierre De Rop < > [email protected]> > >>>>>> wrote: > >>>>>>>> > >>>>>>>>> Hello David, > >>>>>>>>> > >>>>>>>>> The code we are using to configure our components is old, at at > the > >>>>>> time we wrote it, configadmin was not supporting multi-location. > But I > >>>> do > >>>>>> agree, we can now use the "?" multi-location. > >>>>>>>>> > >>>>>>>>> Now, I'm sorry but I'm still seeing another NPE (sometimes, not > >>>>>> always): > >>>>>>>>> > >>>>>>>>> 2013-10-26 11:45:44,209 CM Event Dispatcher (Fire > >> ConfigurationEvent: > >>>>>> pid=sipagent) ERROR osgi - [43] Unexpected problem delivering > >>>>>> configuration event to [org.osgi.service.cm.ConfigurationListener, > >>>> id=102, > >>>>>> > >>>> > >> > bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar] > >>>>>>>>> > >>>>>>>>> java.lang.NullPointerException > >>>>>>>>> at > >>>>>> > >>>> > >> > org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226) > >>>>>>>>> at > >>>>>> > >>>> > >> > org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396) > >>>>>>>>> at > >>>>>> > >>>> > >> > org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:344) > >>>>>>>>> at > >>>>>> > >>>> > >> > org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032) > >>>>>>>>> at > >>>>>> > >>>> > >> > org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002) > >>>>>>>>> at > >>>>>> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103) > >>>>>>>>> at java.lang.Thread.run(Thread.java:722) > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> I'm not sure, but it seems that ConfigAdmin is providing a null > >>>>>> dictionary, when delivering a CM_LOCATION_CHANGED event ? if > correct, > >>>> then > >>>>>> Is this a normal behavior ? > >>>>>>>>> > >>>>>>>>> This is strange; perhaps I shall start a new integration test ? > >>>>>>>>> > >>>>>>>>> /Pierre > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Sat, Oct 26, 2013 at 9:54 AM, David Jencks < > >>>> [email protected]> > >>>>>> wrote: > >>>>>>>>> Hi Pierre, > >>>>>>>>> > >>>>>>>>> This pointed out a logic error I introduced for Felix 3651. I > >> opened > >>>>>> https://issues.apache.org/jira/browse/FELIX-4293 and fixed the > error > >> I > >>>>>> found which I think explains the NPE. Could you check this? > >>>>>>>>> > >>>>>>>>> Could I ask what you are trying to do by setting the > bundleLocation > >>>> to > >>>>>> null? If you want to allow any bundle to receive the configuration > >> you > >>>>>> could use multi-location support and set the location to "?" With > the > >>>> code > >>>>>> you have now, if the configuration is already in use by a DS > >> component, > >>>> the > >>>>>> location changed event will result in the bundle location being > reset > >>>> back > >>>>>> to what it was. > >>>>>>>>> > >>>>>>>>> thanks! > >>>>>>>>> david jencks > >>>>>>>>> On Oct 25, 2013, at 8:32 AM, Pierre De Rop < > [email protected] > >>> > >>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> Hi David, > >>>>>>>>>> > >>>>>>>>>> thanks; The fix is fixing the problem :-) > >>>>>>>>>> > >>>>>>>>>> but ... there's now a new different problem: i'm now sometimes > >>>>>> getting this > >>>>>>>>>> NPE, after SCR is receiving a CM_LOCATION_CHANGED event: > >>>>>>>>>> > >>>>>>>>>> 2013-10-25 16:11:44,674 CM Event Dispatcher (Fire > >>>> ConfigurationEvent: > >>>>>>>>>> pid=sipagent) ERROR osgi - [43] Unexpected problem delivering > >>>>>>>>>> configuration event to > [org.osgi.service.cm.ConfigurationListener, > >>>>>> id=102, > >>>>>>>>>> > >>>>>> > >>>> > >> > bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar] > >>>>>>>>>> > >>>>>>>>>> java.lang.NullPointerException > >>>>>>>>>> at > >>>>>>>>>> > >>>>>> > >>>> > >> > org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226) > >>>>>>>>>> at > >>>>>>>>>> > >>>>>> > >>>> > >> > org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396) > >>>>>>>>>> at > >>>>>>>>>> > >>>>>> > >>>> > >> > org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:390) > >>>>>>>>>> at > >>>>>>>>>> > >>>>>> > >>>> > >> > org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032) > >>>>>>>>>> at > >>>>>>>>>> > >>>>>> > >>>> > >> > org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002) > >>>>>>>>>> at > >>>>>> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103) > >>>>>>>>>> at java.lang.Thread.run(Thread.java:722) > >>>>>>>>>> > >>>>>>>>>> Perhaps a new jira issue shall be opened ? > >>>>>>>>>> > >>>>>>>>>> I think we are getting a CM_LOCATION_CHANGED event because in > our > >>>>>>>>>> application, we populate configuration admin by doing something > >> like > >>>>>> this: > >>>>>>>>>> > >>>>>>>>>> Configuration cfg = cm.getConfiguration(pid, null) > >>>>>>>>>> if (config.getBundleLocation() != null) { > >>>>>>>>>> config.setBundleLocation(null); > >>>>>>>>>> } > >>>>>>>>>> > >>>>>>>>>> The setBundleLocation(null) is probably useless, but this leads > >> to a > >>>>>>>>>> CM_LOCATION_CHANGED event, which then sometimes ends up with the > >>>> NPE. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Friday, October 25, 2013, David Jencks < > [email protected] > >>> > >>>>>> wrote: > >>>>>>>>>>> Hi Pierre, > >>>>>>>>>>> > >>>>>>>>>>> You are so good at writing useful tests!! > >>>>>>>>>>> > >>>>>>>>>>> I found a place to call setTargets(getProperties()) from inside > >>>>>>>>>> ComponentFactoryImpl that would have fewer side effects. Could > >> you > >>>>>> see if > >>>>>>>>>> this makes your actual applications work properly? I'm > uploading > >> a > >>>>>>>>>> snapshot. > >>>>>>>>>>> > >>>>>>>>>>> many thanks > >>>>>>>>>>> david jencks > >>>>>>>>>>> > >>>>>>>>>>> On Oct 24, 2013, at 6:17 AM, Pierre De Rop < > >> [email protected] > >>>>> > >>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Hi David, > >>>>>>>>>>>> > >>>>>>>>>>>> Since this application is complex, I'm not able to provide > logs > >>>>>> because > >>>>>>>>>>>> there are hundreds of components involved which are not mine, > >> and > >>>>>> for > >>>>>>>>>> now, > >>>>>>>>>>>> I'm not able to diagnose the problem. > >>>>>>>>>>>> > >>>>>>>>>>>> But I have created FELIX-4290, and joined to it an integration > >>>> test > >>>>>> which > >>>>>>>>>>>> seems to reproduce the kind of problem I think I'm having in > my > >>>>>>>>>>>> application. I also joined the proposed patch. > >>>>>>>>>>>> > >>>>>>>>>>>> I did not have time to test the patch you suggested regarding > >> the > >>>>>>>>>>>> SingleComponentManager.reconfigure method, so let's continue > to > >>>>>>>>>> investigate > >>>>>>>>>>>> using the jira issue and the test I attached to it. > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks; > >>>>>>>>>>>> > >>>>>>>>>>>> /Pierre > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On Thu, Oct 24, 2013 at 12:27 AM, David Jencks < > >>>>>> [email protected] > >>>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> Hi Pierre, > >>>>>>>>>>>>> > >>>>>>>>>>>>> I believe you that this code path doesn't work :-) > >>>>>>>>>>>>> > >>>>>>>>>>>>> I think there should be a less invasive way to fix this. By > >> any > >>>>>> chance > >>>>>>>>>>>>> can you get a debug-enabled log from when this problem > occurs? > >>>> It > >>>>>> would > >>>>>>>>>>>>> help confirm my suspicions of what might be missing. > >>>>>>>>>>>>> > >>>>>>>>>>>>> FWIW I suspect SingleComponentManager.reconfigure is missing > a > >>>>>> check for > >>>>>>>>>>>>> m_factoryProperties here (line 561): > >>>>>>>>>>>>> > >>>>>>>>>>>>> // nothing to do if there is no configuration (see > >>>>>> FELIX-714) > >>>>>>>>>>>>> if ( configuration == null && m_configurationProperties > >>>> == > >>>>>>>>>>>>> null ) > >>>>>>>>>>>>> { > >>>>>>>>>>>>> log( LogService.LOG_DEBUG, "No configuration > >> provided > >>>>>> (or > >>>>>>>>>>>>> deleted), nothing to do", null ); > >>>>>>>>>>>>> return; > >>>>>>>>>>>>> } > >>>>>>>>>>>>> > >>>>>>>>>>>>> Unless we can't figure anything out for sure I'd prefer to > fix > >>>> this > >>>>>>>>>> before > >>>>>>>>>>>>> the release. > >>>>>>>>>>>>> > >>>>>>>>>>>>> thanks > >>>>>>>>>>>>> david jencks > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Oct 23, 2013, at 3:09 PM, Pierre De Rop < > >>>> [email protected] > >>>>>>> > >>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> (sorry to do all this noise while you are releasing ...) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> We are indeed using factory components; and today, I finally > >>>>>> found and > >>>>>>>>>>>>>> fixed a cycle, using the Apache Service Diagnostic tool; and > >> I'm > >>>>>> going > >>>>>>>>>>>>>> further on but now I'm facing another problem which I did > not > >>>>>> have in > >>>>>>>>>> the > >>>>>>>>>>>>>> scr 1.6.2. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> So, I would like to discuss about this new problem with you > >>>>>> before you > >>>>>>>>>>>>> redo > >>>>>>>>>>>>>> a release, in order to decide if this problem (if there is > >>>> really > >>>>>> one > >>>>>>>>>> ?) > >>>>>>>>>>>>>> shall be addressed now or after the upcoming release ? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> So, in our application, we are extensively using factory > >>>>>> components > >>>>>>>>>>>>>> (@Component(factory=XXX")). > >>>>>>>>>>>>>> When we instantiate a factory component (using > >>>>>>>>>>>>>> ComponentFactory.newInstance()), We pass to the > newInstance() > >>>>>> method > >>>>>>>>>> some > >>>>>>>>>>>>>> additional component properties which may also contain some > >>>> target > >>>>>>>>>>>>> filters. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> This allows to dynamically configure the filter of some > >>>> References > >>>>>>>>>>>>> declared > >>>>>>>>>>>>>> in the factory component. > >>>>>>>>>>>>>> in the scr 1.6.2, this mechanism was working fine. But using > >>>>>> trunk, > >>>>>>>>>> this > >>>>>>>>>>>>>> does not work all the time. Some target filters seem to be > >>>>>> correctly > >>>>>>>>>>>>>> configured, and some others are not (I'm not sure, actually, > >>>> it's > >>>>>> late > >>>>>>>>>>>>> ...). > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> So, it looks like sometimes, some target filters are not > >> updated > >>>>>> before > >>>>>>>>>>>>>> activating components ? or factory components ? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I'm not sure but this might be related to the old > FELIX-3726. > >>>>>>>>>>>>>> Now, interestingly, I did the following patch and my > >> application > >>>>>> is now > >>>>>>>>>>>>>> working fine: In the AbstractComponentManager class, I > >>>>>> systematically > >>>>>>>>>>>>>> update target filters, like this: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> +++ > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>> > >>>>>> > >>>> > >> > src/main/java/org/apache/felix/scr/impl/manager/AbstractComponentManager.java > >>>>>>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>> > >>>> > >> > >> > >
