sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominik Smogór (JIRA) <j...@apache.org>
Subject [jira] [Created] (SLING-6852) A question about reliability of keeping non DS tracked references
Date Fri, 12 May 2017 10:33:04 GMT
Dominik Smogór created SLING-6852:
-------------------------------------

             Summary: 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)

Mime
View raw message