[
https://issues.apache.org/jira/browse/FELIX-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13822236#comment-13822236
]
Guillaume Nodet commented on FELIX-4313:
----------------------------------------
All the other implementations of AbstractCustomizer do not hold any lock while
calling getTracker().deactivate(), so if a lock is needed, we'd have to fix
them all.
In addition, the getTracker() and deactivate() methods seems thread safe at
first glance, as they access variables flagged as volatile and the deactivate
method has itself an internal synchronization block. It follows the same
pattern as lots of other methods in the ServiceTracker, i.e. get the volatile
tracked object, check for null, and process the real call while holding a lock
on this object.
> Bad synchronization in scr where a lock is held while ungetting a service
> -------------------------------------------------------------------------
>
> Key: FELIX-4313
> URL: https://issues.apache.org/jira/browse/FELIX-4313
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.8.0
> Reporter: Guillaume Nodet
> Assignee: Guillaume Nodet
> Priority: Minor
> Fix For: scr-1.8.2
>
>
> The problem is located in DependencyManeger$SingleStaticCustomizer.close()
--
This message was sent by Atlassian JIRA
(v6.1#6144)
