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

Carsten Ziegeler commented on FELIX-5507:
-----------------------------------------

I didn't say to use the system bundle, I wanted to use the SCR bundle to get 
the configuration admin.
Where in the spec is defined that the extended bundle must have permissions to 
use config admin if it is using DS and configurations? Is this really required?
So every extended bundle needs to have service permission to get CA and 
permission to read configuration? Do we check this?

If you think about sub systems or any other isolation, we really have a strange 
setup now. SCR is using the system bundle to find all bundles to be extended. 
These could be in subsystems and it is then assuming that all of these bundles, 
regardless of where they are have visibility to the same CA api. It might be 
the most sensible setup, but it is definitely not the only one. For example, if 
I have a subsystem with some app bundles, no bundle in there might need CA 
directly, so my subsystem is not importing the CA api. Which means SCR will 
fail to extend these bundles. Is this what we want to do?

And as said I'm going to hunt the real cause - but that is independent of this 
discussion

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

Reply via email to