felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jencks (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (FELIX-4290) [DS] Issue with factory components with required configuration
Date Fri, 25 Oct 2013 07:04:30 GMT

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

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

    Summary: [DS] Issue with factory components with required configuration  (was: Issue with
factory components)

> [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.8.0
>            Reporter: Pierre De Rop
>         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.1#6144)

Mime
View raw message