Mailing-List: contact dev-help@sling.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@sling.apache.org
Date: Fri, 12 May 2017 10:53:04 +0000 (UTC)
From: "Justin Edelson (JIRA)" <jira@apache.org>
To: dev@sling.apache.org
Message-ID: <JIRA.13071500.1494585163000.196353.1494586384296@Atlassian.JIRA>
In-Reply-To: <JIRA.13071500.1494585163000@Atlassian.JIRA>
References: <JIRA.13071500.1494585163000@Atlassian.JIRA> <JIRA.13071500.1494585163036@jira-lw-us.apache.org>
Subject: [jira] [Commented] (SLING-6852) A question about reliability of
 keeping non DS tracked references
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Fri, 12 May 2017 10:53:10 -0000


    [ https://issues.apache.org/jira/browse/SLING-6852?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1600=
7947#comment-16007947 ]=20

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 a=
gain it controls their lifecycle. So you could say that ModelAdapterFactory=
 is responsible for the lifecycle of those services, but there's no "listen=
er 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 ap=
plications.

> 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=C3=B3r
>            Priority: Minor
>
> It's a generic best practice question but illustrated on an example withi=
n sling models.
> We have 2 kind osgi services being in parent - child=20
> 1. a factory service that programmatically registers number listener serv=
ices=20
> 2. the listener services.
> The listener services are called asynchronously (usually in a white board=
 manner) by some 3rd party components.=20
> Now, the listener services implementations are keeping a simple object re=
ferences to the parent service. Osgi is not aware of this link and is not t=
racking it in any way.
> An example of such a relation is here http://grepcode.com/file/repo1.mave=
n.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  ModelPackageBundleLis=
tener which self register themselves with BundleTracker.
> No the question is: what guarantee do we have that the child services wil=
l never use defunct instances of parent objects after they have been deacti=
vated 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 res=
tarts?
> (disclaimer: I've used the highest sling models version that's there on g=
repcode)


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