[
https://issues.apache.org/jira/browse/FELIX-4314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Offermans resolved FELIX-4314.
-------------------------------------
Resolution: Fixed
Implemented.
> Split service registration to solve visibility issue in autoconf
> ----------------------------------------------------------------
>
> Key: FELIX-4314
> URL: https://issues.apache.org/jira/browse/FELIX-4314
> Project: Felix
> Issue Type: Bug
> Components: Deployment Admin
> Reporter: Marcel Offermans
> Assignee: Marcel Offermans
>
> The current implementation of autoconf registers itself as both a
> ResourceProcessor and EventHandler. The first because, obviously, it is a
> resource processor. The second because it wants to know when the deployment
> session ends, which is signalled through an event.
> This creates an interesting visibility issue, especially when bootstrapping
> an OSGi framework by installing a deployment package containing "everything".
> Initially this means there is just some management agent available. Through
> DeploymentAdmin the agent installs the deployment package which contains
> bundles and configuration data. The bundles that are included contain
> EventAdmin and ConfigurationAdmin.
> Let's also assume that the management agent has no dependency on EventAdmin,
> not even its API, because a) it does not want to depend on it (through an
> ImportPackage) and b) it does not want to provide and depend on it either
> (because it tries to isolate itself as much as possible from the rest of the
> framework).
> This creates an interesting problem: because autoconf registers as both a
> ResourceProcessor and EventHandler, and EventHandler is not visible to the
> agent, it will *not* see the resource processor either. Therefore the
> deployment will fail in a way that is hard to debug (if you inspect the
> registry, the service is there, it's just that the agent is not allowed to
> see it).
> The easiest solution is to split the registration into two. First just
> register as a ResourceProcessor and then, separately, also register as an
> EventHandler. In fact, in this case, we can defer the latter a bit until we
> are actually interested in the event.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
