[
https://issues.apache.org/jira/browse/FELIX-5315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15404697#comment-15404697
]
James Watkins-Harvey commented on FELIX-5315:
---------------------------------------------
Thanks for your clarifications! I had indeed missed a few key facts about the
code's architecture, and was therefore under the impression that a
{{caReference}} could be passed to a bundle context that would not be able to
resolve it. However, I see now how the code indeed ensure that 1) there is
exactly one RegionConfigurationSupport for each ConfigurationAdmin
implementation bundle, 2) the correct RegionConfigurationSupport is used on
resolving some component, and 3) that the {{caReference}} can consequently only
be passed to a bundle context for which that reference would be valid. That
sounds good for the multiple region case.
As for the other case I mentioned, that is manipulation of bundle/service
visibility, for example using service hooks, I'm not absolutely certain that it
would not be possible to create a problematic setup, but it seems indeed that
the current solution should also handle pretty much any case properly, as long
as the second precondition holds (that is, only one config admin service
visible to each extended bundle).
Good job ;)
> Unexpected release of ConfigurationAdmin service in
> RegionConfigurationSupport
> -------------------------------------------------------------------------------
>
> Key: FELIX-5315
> URL: https://issues.apache.org/jira/browse/FELIX-5315
> Project: Felix
> Issue Type: Bug
> Components: Configuration Admin, Declarative Services (SCR)
> Affects Versions: scr-2.0.4
> Reporter: James Watkins-Harvey
> Assignee: David Jencks
> Fix For: scr-2.0.6
>
>
> In commit 978a710, RegionConfigurationSupport has been modified to obtain the
> ConfigurationAdmin service through the ConfigurationAdmin's bundle context
> (in getConfigAdmin(), around line 633). However, services acquired through
> that method are then released using the impersonated bundle's context (for
> example in the finally block of configureComponentHolder(ComponentHolder),
> around line 186, and the finally block of getConfigurationInfo(TargetedPID,
> TargetedPID, ComponentHolder, BundleContext), around line 465).
> This cause leak of service on the ConfigurationAdmin's bundle context, as
> well as unexpected early release of services on impersonated bundle contexts,
> causing an IllegalStateException("Configuration Admin service has been
> unregistered") being thrown in
> ConfigurationAdminImpl#getConfigurationManager().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
