[
https://issues.apache.org/jira/browse/FELIX-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-4050:
---------------------------------
Fix Version/s: dependencymanager.runtime-3.2.0
> Named dependencies are not injected if new dependencies are added at init
> phase.
> --------------------------------------------------------------------------------
>
> Key: FELIX-4050
> URL: https://issues.apache.org/jira/browse/FELIX-4050
> Project: Felix
> Issue Type: Bug
> Components: Dependency Manager
> Affects Versions: dependencymanager-3.1.0
> Reporter: Tuomas Kiviaho
> Assignee: Pierre De Rop
> Fix For: dependencymanager.runtime-3.2.0
>
> Attachments: FELIX-4050.patch
>
>
> Spec says that "In the Init method, you are yet allowed to add some
> additional dependencies (but using the API)."
> I guess this means that I am allowed to call Component.add(). This leads to
> state transition for instance when new service dependency is added since it's
> started right away because component is already instantiated at this point.
> Component.dependencyAvailable() is called if service tracker finds a match
> right away and this in turn starts the state change calculation.
> Problem is that State uses components current instantiated status to
> determinate whether it is bound or not and not the status what the component
> was given to the activateService() method. State change calculation
> transitions to bound state prematurely because component is now instantiated.
> All required dependencies are available, because component is still unaware
> of forthcoming named dependencies at this point.
> I suggest that some sort of placeholder dependencies are used which the named
> dependencies will replace when they are created/configured. This also
> approach also preserves the order in which dependencies were actually added
> to the component. In the future there could be a new is/SetActive property to
> DependencyActivation which could be used to turn on/off an already added
> dependencies. Then named dependencies could be used as such instead of
> placeholders and user could even configure them directly.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
