[
https://issues.apache.org/jira/browse/FELIX-6335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17201033#comment-17201033
]
Tom Watson commented on FELIX-6335:
-----------------------------------
My guess is that Equinox and Felix Frameworks have the same behavior with
respect to cloning service properties on registration and setProperties. For
reference here is Equinox:
https://github.com/eclipse/rt.equinox.framework/blob/R4_17/bundles/org.eclipse.osgi/container/src/org/eclipse/osgi/internal/serviceregistry/ServiceProperties.java#L105
The collections you mention that do not work
{{Collections.synchronizedCollection(propList) }} and
{{Collections.unmodifiableCollection(propList)}} are not cloneable so the
framework ends up using the value as-is in the service properties. The problem
with your test is that you then modify the collection which is backing the
synchronized/unmodifiable collection which changes the actual properties for
the service registration without actually sending any event (because the
framework cannot detect you did this to send the event until you call
setProperties). Then you call setProperties with the "new" values. The issue
is the framework attempts to see if your changes now make the current target
filter no longer match, so we can send a MODIFIED_ENDMATCH to the listener, but
to do this we first have to make sure the previous properties do match. But
here you changed them under the covers so the Framework thinks that the target
did not match before and it still doesn't match now so it never sends the
MODIFIED_ENDMATCH event for SCR to process.
For the test {{testExampleNotWorking1}} you use a LinkedList directly which is
cloneable and that works for me with Equinox. If that does not work with Felix
then my guess is that the Felix Framework does no checking for cloneable. I
have to check with the specification on if it provides details on how service
property values must be protected against outside modification like this. But
my advise in general is to not modify the values of the service properties
outside of the service registration. The framework will never be able to
generally protect against all object types.
I could see how it would be able to detect different types of collections and
do its own copying when clone isn't available, but I am not sure the framework
is obligated to do that. Regardless, this is not an SCR issue. Moving to
Framework, perhaps Karl or others think the framework should protect more
against this by copying more for the service property values.
> 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)
