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