You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "David Jencks (JIRA)" <ji...@apache.org> on 2014/08/06 04:34:11 UTC

[jira] [Updated] (FELIX-4290) [DS] Issue with factory components with required configuration

     [ https://issues.apache.org/jira/browse/FELIX-4290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Jencks updated FELIX-4290:
--------------------------------

    Fix Version/s: scr-1.8.0

> [DS] Issue with factory components with required configuration
> --------------------------------------------------------------
>
>                 Key: FELIX-4290
>                 URL: https://issues.apache.org/jira/browse/FELIX-4290
>             Project: Felix
>          Issue Type: Bug
>          Components: Declarative Services (SCR)
>    Affects Versions: scr-1.6.2
>            Reporter: Pierre De Rop
>            Assignee: David Jencks
>             Fix For: scr-1.8.0
>
>         Attachments: FELIX-4290.patch, FELIX-4290.test.tgz
>
>
> This issue is related to the dev post at http://www.mail-archive.com/dev@felix.apache.org/msg31209.html
> While doing some non regression tests on the scr/trunk (before doing 1.8 release, I came across some problems with some of our applications using declarative service.
> What am I observing is that many factory components are unsatisfied and our application is not coming up at all (It was working fine with scr 1.6.2).
> Now, I have joined to this issue an integration test which seems to reproduce the problem, and also a candidate fix.
> The ComponentFactoryWithTargetFiltersTest test is using the integration_test_targetfilter_factory_components.xml and does the following:
> 1) it enables the "factory.component.reference.targetfilter" component.
> This component has a required configuration, is a factory component, and has a dynamic reference 1..1 on a SlmpleService instance.
> 2) Then we instantiate two SimpleService instances: The first one contains a "value=service1" service property, and the second one contains the "value=service2" service property.
> 3) at this point, we create the configuration for the component factory.
> Notice that at this point, the factory component should transit from STATE_UNSATISFIED to STATE_FACTORY. but it seems that this is not the case and we see in logs:
> log level: 3 D=14:55:12,837 T=Thread[Configuration Updater,5,main]: [factory.component.reference.targetfilter(0)] Configuration PID updated for Component Factory
> log level: 3 D=14:55:12,837 T=Thread[Configuration Updater,5,main]: [factory.component.reference.targetfilter(0)] Current ComponentFactory state=4
> log level: 4 D=14:55:12,837 T=Thread[Configuration Updater,5,main]: [factory.component.reference.targetfilter(0)] Attempting to activate unsatisfied component
> log level: 4 D=14:55:12,837 T=Thread[Configuration Updater,5,main]: [factory.component.reference.targetfilter(0)] ActivateInternal
> log level: 4 D=14:55:12,837 T=Thread[Configuration Updater,5,main]: [factory.component.reference.targetfilter(0)] Activating component from state 4
> log level: 4 D=14:55:12,837 T=Thread[Configuration Updater,5,main]: [factory.component.reference.targetfilter(0)] Dependency not satisfied: ref
> log level: 4 D=14:55:12,837 T=Thread[Configuration Updater,5,main]: [factory.component.reference.targetfilter(0)] Not all dependencies satisfied, cannot activate
> 4) Then we lookup the ComponentFactory for the "factory.component.reference.targetfilter" component, and we pass to the CF.newInstance() method a Hashtable with the following target filter:
> "ref.target="(value=service2)")
> 4) and finally, we expect the component to be bound to SimpleService2 (because we have configured the target filter (ref) to "(value=service2)".
> Initially, i though that the problem was coming from target filters. But it seems that the problem comes from the fact that the factory component stays unsatisfied, event if we provide the configuration and even when the two SImpleService instances are registered.
> And the test fails like this:
> junit.framework.AssertionFailedError: expected:<64> but was:<4>
>         at junit.framework.Assert.fail(Assert.java:57)
>         at junit.framework.Assert.failNotEquals(Assert.java:329)
>         at junit.framework.Assert.assertEquals(Assert.java:78)
>         at junit.framework.Assert.assertEquals(Assert.java:234)
>         at junit.framework.Assert.assertEquals(Assert.java:241)
>         at junit.framework.TestCase.assertEquals(TestCase.java:409)
>         at org.apache.felix.scr.integration.ComponentFactoryWithTargetFiltersTest.test_component_factory(ComponentFactoryWithTargetFiltersTest.java:82)
> Now, if I apply the proposed attached patch, then the integration test is successful and my application is also coming up correctly.
> (I did not have time to try to follow what David is suggesting in the dev post, regarding a potential issue in SingleComponentManager.reconfigure() and a missing check regarding  m_factoryProperties).



--
This message was sent by Atlassian JIRA
(v6.2#6252)