[
https://issues.apache.org/jira/browse/FELIX-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651630#comment-13651630
]
Tuomas Kiviaho commented on FELIX-4050:
---------------------------------------
I did some proof-of-concept an found out that current implementations
themselves could function as placeholder thus turning it to a dependency that
has been added to the component prematurely. There dependencies only track
components calling such methods as start/stop (and invokeAdded/invokeRemoved)
in order to postpone activation until appropriate time when named dependency is
fully configured (finally figured out what setInstanceBound was actually for
:-) ).
I had to mark these components available until activation occurs so that init
phase would not be blocked from being triggered. Other that that the state
machine seemed to cope well. One curious thing is that when component goes from
zero to max in one state transition, it seems to skip startTrackingRequired and
go straight to activateService. This effectively skips calls to dependency
activation start but luckily invokeAdded is called so that I could use it to
keep track on interesting parties.
> 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
