[
https://issues.apache.org/jira/browse/FELIX-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15864554#comment-15864554
]
Karl Pauls commented on FELIX-5507:
-----------------------------------
Ok, I looked at this issue a little bit more in depth and I think I can see
what is going on.
When we did the implicit bootdelegation we really had one specific corner case
in mind namely, something outside the framework (and more specifically, classes
inside the jdk) assumes it can just use the class loader of the class of an
object provided to it to get access to stuff it sees. That used to be the case
for example in certain scenarios with swing. In order to remedy the somewhat
awkward situation that people new to OSGi constantly had problems with this
kind of thing we introduced our “magic hack” that would try to detect this
situation as a last resort and bootdelegate automagically.
After looking at that code again I do think it could be improved but overall it
still seems to be sound in regard to its original purpose (and it was always
the case that in more complicated scenarios, especially around embedding, we
knew it needed to be turned off - hence, the possibility to disable it).
However, what happens here is that we sort of ignored the fact that it is going
to happen on all classloads when we did the tests for service assignability
later on (iirc, this is still code form the beginning of R4 - at least in its
origins). As a consequence, we have a problem in the service lookup path when,
1) the class that instigates the lookup is coming from the outside
2) and the service class can actually be loaded from the outside but isn’t
assignable to the class of the service
3) and both, the requirer and the provider, don’t have a wire to the package of
the service class.
It is this specific case that is happening here and it goes like this:
The scr looks for ConfigAdmin via the bundle context of an extended bundle.
That makes it so that the extended bundle doesn’t have a wire to the
ConfigAdmin package (as it doesn’t use it itself) and the ConfigAdmin bundle
provides the package - hence, doesn’t have a wire either (3). Next, scr uses a
ServiceTracker to track the ConfigAdmin and is importing the
org.osgi.util.tracker package from the system bundle - in other words, the
ServiceTracker class instigates the lookup and is coming from the outside (1).
Finally, it just so happens that there is a ConfigAdmin class outside as well
that comes with equinox in websphere (2).
As a result, when the lookup happens the ConfigAdmin isn’t returned because due
to the triggered boot delegation we think it might not be assignable. Now, in
the second case, when the ConfigAdmin bundle gets restarted later what happens
is that the tracker isn’t instigating the lookup. In that case, it gets the
service via a service event which _does not_ trigger the magic and in turn
makes it so that the service is delivered (thats why it works after a restart
of the ConfigAdmin bundle but _not_ after a restart of the scr bundle).
TL;DR For now, the workaround with the current framework is to turn of implicit
bootdelegation. For the future, we need to stop trying to implicitly
bootdelegate in the service lookup.
If nobody complains, I will go ahead and create a new issue for making it so
that we don’t implicitly bootdelegate when we lookup the class for checking
assignability of services and link it to this issue. I’ll try to get to
addressing it soon as I want to get this into a new framework release this week.
> ConfigurationAdmin not visible to bundles
> -----------------------------------------
>
> Key: FELIX-5507
> URL: https://issues.apache.org/jira/browse/FELIX-5507
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: framework-5.6.1
> Reporter: Carsten Ziegeler
> Assignee: Carsten Ziegeler
> Fix For: framework-5.6.2
>
>
> 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
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
