Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Date: Thu, 16 Feb 2017 22:47:41 +0000 (UTC)
From: "David Jencks (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Message-ID: <JIRA.13036564.1484919816000.104270.1487285261745@Atlassian.JIRA>
In-Reply-To: <JIRA.13036564.1484919816000@Atlassian.JIRA>
References: <JIRA.13036564.1484919816000@Atlassian.JIRA> <JIRA.13036564.1484919816583@jira-lw-us.apache.org>
Subject: [jira] [Commented] (FELIX-5507) ConfigurationAdmin might not be
 visible to SCR implementation
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 16 Feb 2017 22:47:46 -0000


    [ https://issues.apache.org/jira/browse/FELIX-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15870814#comment-15870814 ] 

David Jencks commented on FELIX-5507:
-------------------------------------

Philosophically I think that if OSGI has to resort to reflection to access an osgi spec interface we've failed.

On the other hand there might be a potential use case for this:
Commercial server based on OSGI that is not updated all that often (say stuck at R7 for the next 10 years)
subsystem in it that wants to use an R8 config admin (assuming R8 updates the config admin spec).  This can't be wired to the R7 config admin api from the server.  Is this a realistic scenario or will the R8 config admin also require R8 framework so not run in the R7 server anyway?

Assuming my reservations about doing this are overruled:
Finding the bundle for the ca is already  done in RegionConfigurationSupport, so that can be used to load the SynchronousConfigurationListener and ManagedService (for configuration plugin support) interfaces in order to create dynamic proxies.

Contrary to some other suggestions, I think that there should only be one code path using proxies for objects we create and reflection on stuff we get from config admin, and no separate path for compatible config admin apis.  No one is ever going to use this support, so if we want it to work we have to use the code path all the time to find the bugs.

I will reiterate again:
- requiring a subsystem to import the config admin api as well as the ds api is not a large burden.
- I think waiting until someone requests this feature because they actually want to use it would be wise.

Karl:

"In the latter case, the bundle will get the configurations from the CM visible to the bundle but the SCR must deal with the possibility that the bundle might not be wired to the same CM the SCR can see."
This is not quite right.  We want to look for the CM service visible to the extended bundle, but the extended bundle doesn't necessarily have any wires to the CM api.  Currently we deal with the case where the CM api is not the same as the CM api visible to DS by not using it and emitting an error message (to be improved).  I think  that's fine.

> ConfigurationAdmin might not be visible to SCR implementation
> -------------------------------------------------------------
>
>                 Key: FELIX-5507
>                 URL: https://issues.apache.org/jira/browse/FELIX-5507
>             Project: Felix
>          Issue Type: Bug
>          Components: Declarative Services (SCR)
>    Affects Versions: scr-2.0.8
>            Reporter: Carsten Ziegeler
>            Assignee: Carsten Ziegeler
>             Fix For: scr-2.1.0
>
>
> We have one case where the extended bundles do not see the configuration admin service. Interestingly the same application runs fine everywhere else, but just on a special environment (windows, ibm java inside Websphere) we have this problem reproducibly.
> Using the system bundle context instead of the bundle context of the extended bundle in ConfigAdminTracker solves the problem.
> Interestingly only the bundles started last (2 out of probably 80) see the configuration admin.
> It could also be that a faulty service hook is involved, although I'm not yet aware of such a hook
> Update: after some discussion, some issues in the framework have been identified, but also the SCR implementation is not 100% correct: as it is using the bundle context of the extended bundle, it might get a configuration admin which interface is not visible to SCR. Therefore it should revert to reflection to access the configuration admin.


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