[
https://issues.apache.org/jira/browse/FELIX-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13664926#comment-13664926
]
Pierre De Rop commented on FELIX-4050:
--------------------------------------
Ah Ok ! thanks; I understand now.
The component state calculation is messing up if init adds some *available*
dependencies using the API and if init also returns a map for configuring other
named annotated dependencies.
It may even also mess up if no map is returned and if several dependencies are
added using the API, but not atomically (using separate
Component.add(Dependency) method calls). But in the latter case, multiple
dependencies should be added atomically using Component.add(List) single method
call.
Anyway, as you explained, adding the dependencies with the API may change the
state to BOUND state *before* the runtime possibly configures named
dependencies after the init method is called (see ServiceLifecycleHandler.java,
in the runtime).
All this is an edge case I did not expect, because dependencies are usually
declared either using annotations or using the programmatic API, but not using
a mix of annotations + code using directly the API (Component.add() method).
Ok, I think the easiest way to fix this issue with minimal impact consists in
adding an hidden "toggle" dependency, which allows to activate all dependencies
*after* init method is called and also *after* all named dependencies are
possibly configured.
The patch is ready and seems to work, but I prefer to write and commit a test
about this issue because applying the patch.
> 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
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
