[
https://issues.apache.org/jira/browse/FELIX-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839950#comment-15839950
]
Carsten Ziegeler commented on FELIX-5507:
-----------------------------------------
[~tjwatson] Yes, correct, the SCR bundle might have a similar issue - which
proofs that we can't simply think that one solution fits all use cases.
I tend to agree that it makes sense to use a CA from the POV of the extendee
bundle. however the simplest use case an app subsystem with a simple bundle and
a simple DS service that is not importing the CA package will simply not work.
I guess it would be fine to say, if that app wants to use configurations it
requires an import of CA, however just looking at the bundle does not tell you
that this import is required.
Or you have two app subsystems, each with their own configuration admin
supporting and containing different CA versions, then the current SCR impl will
break as well.
Looking at this, i guess my suggestion of the switch does not really make
sense. It's maybe rather that the current code of using the extendee bundle
context to get the CA is correct but it should then use reflection or any other
trick as in fact that extendee bundle might be wired to a different CA package
than SCR. Or at least we should catch the ClassCastException and provide a
meaningful log message.
> ConfigurationAdmin not visible to bundles
> -----------------------------------------
>
> 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
> 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
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
