You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Justin Edelson (JIRA)" <ji...@apache.org> on 2017/05/12 10:53:04 UTC
[jira] [Commented] (SLING-6852) A question about reliability of
keeping non DS tracked references
[ https://issues.apache.org/jira/browse/SLING-6852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16007947#comment-16007947 ]
Justin Edelson commented on SLING-6852:
---------------------------------------
it would be best to ask generic OSGi questions on the osgi-dev mailing list.
In this specific example, I'm not sure what you mean by "listener services". ModelAdapterFactory creates a BundleListener *object* whose lifecycle it controls. In turn, the BundleListener registers a number of services, but again it controls their lifecycle. So you could say that ModelAdapterFactory is responsible for the lifecycle of those services, but there's no "listener services" per se.
I should note that while this pattern is relatively common in Sling, it isn't something recommended for "normal" users of OSGi. Sling is a provider of infrastructure and so ends up using more low-level features than normal applications.
> 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)