felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jencks (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-5507) ConfigurationAdmin might not be visible to SCR implementation
Date Thu, 16 Feb 2017 22:47:41 GMT

    [ 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)

Mime
View raw message