[
https://issues.apache.org/jira/browse/FELIX-6335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202362#comment-17202362
]
Tom Watson commented on FELIX-6335:
-----------------------------------
I suspect the fix in issue FELIX-6161 is contributing to the problem you are
observing. Before the fix for FELIX-6161 SCR would only register with simple
filters using the objectClass property to track available services and then it
would apply the target property filter on the event to determine if it matched
for a reference. This allows it to work because it will determine the
MODIFIED_ENDMATCH itself instead of depending on the framework to determine it
for SCR. With the fix for FELIX-6161 now SCR is including the target filter
with the filter it uses for the ServiceListeners to track the available
services and now if MODIFIED_ENDMATCH event is broken then you observe this
issue.
> String+ service property value of certain collection types causes incorrect
> dependency handling
> -----------------------------------------------------------------------------------------------
>
> Key: FELIX-6335
> URL: https://issues.apache.org/jira/browse/FELIX-6335
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: scr-2.1.24
> Reporter: Mark Hoffmann
> Priority: Major
> Attachments: demo.test.zip
>
>
> I think it is an SCR problem, because the problem occurs with Equinox or
> Felix as framework.
> Someone changes a ServiceRegistration for a service *A,* that will be
> updated using setProperties, as soon something changes.
> One of the property values for the registration is String+ that should accept
> a collection.
> Another component *K* should be activated or deactivated, depending on a
> reference binding to *A* with a certain target filter for *A*'s properties
> I experienced that *K* is always activated correctly. But it will not
> de-activate, if the target filter for *A* does not match anymore, when the
> registration properties are changed using certain collection types like e.g.
> _Collections#unmodifiableList_ as property value.
> Changing the value to an ordinary list, everything behaves correct.
> I attached a bnd based test, that illustrates the problem. There are 3 tests
> that are working as expected and 3 tests failing. I deactivated two of these
> failing tests, because feiling just one test casuses an invalid state in the
> framework.
> I am not sure, if the rejection of certain collection types eventually by
> intention. But it has a large impact to the behavior of the framework.
> At least ther should be an warning or exception, that tells the user, that he
> uses invalid types.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
