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

Justin Edelson resolved SLING-6852.
-----------------------------------
    Resolution: Information Provided

> A question about reliability of keeping non DS tracked references
> -----------------------------------------------------------------
>
>                 Key: SLING-6852
>                 URL: https://issues.apache.org/jira/browse/SLING-6852
>             Project: Sling
>          Issue Type: Task
>          Components: Best practices
>    Affects Versions: Sling Models Impl 1.2.0
>            Reporter: Dominik Smogór
>            Priority: Minor
>
> It's a generic best practice question but illustrated on an example within 
> sling models.
> We have 2 kind osgi services being in parent - child 
> 1. a factory service that programmatically registers number listener services 
> 2. the listener services.
> The listener services are called asynchronously (usually in a white board 
> manner) by some 3rd party components. 
> Now, the listener services implementations are keeping a simple object 
> references to the parent service. Osgi is not aware of this link and is not 
> tracking it in any way.
> An example of such a relation is here 
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.sling/org.apache.sling.models.impl/1.2.0/org/apache/sling/models/impl/ModelAdapterFactory.java#900:
> with the ModelAdapterFactory creating instances of  
> ModelPackageBundleListener which self register themselves with BundleTracker.
> No the question is: what guarantee do we have that the child services will 
> never use defunct instances of parent objects after they have been 
> deactivated by OSGI (for whatever reason)?
> Isn't it a potential for race conditions (that partner is used frequently 
> throughout sling code base) during after related to bundle / component 
> restarts?
> (disclaimer: I've used the highest sling models version that's there on 
> grepcode)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to