[
https://issues.apache.org/jira/browse/FELIX-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15870776#comment-15870776
]
David Jencks commented on FELIX-5549:
-------------------------------------
If I understand your code you may have found a bug in the runtime in that
apparently
final Collection<ComponentConfigurationDTO> configs =
scr.getComponentConfigurationDTOs(descDTO);
is returning a collection with a null element.
However the log output you show above is exactly as expected. If you change
the configuration for a factory component where the implementation has no
modified method all the created instances will be destroyed permanently and not
reactivated. This is one of the reasons I regard factory components as
basically useless
112.5.5: Once a component configuration created by the Component Factory has
been deactivated, that com- ponent configuration will not be reactivated or
used again..
The factory itself should not be deactivated, and your log output doesn't show
anything from Booter indicating it was activated or deactivated. Booter is not
notified when the interesting component is activated or deactivated but when
the ComponentFactory is activated or deactivated.
I don't know why you think you want to use a factory component, but you might
be looking more for the extended felix-ds specific behavior enabled by the
@DSExt.PersistentFactoryComponent annotation (from the o.a.f.scr.ext.anno jar).
This makes the lifecycle of a component configuration created by newInstance
the same as for a normal component configuration: there's no problem if not all
the references are available when you call newInstance, and the configuration
stays around until you call destroy, being deactivated and reactivated on
configuration changes and references coming and going.
> Factory component fails to reactivate after config changes
> ----------------------------------------------------------
>
> Key: FELIX-5549
> URL: https://issues.apache.org/jira/browse/FELIX-5549
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
> Environment: Karaf 4.0.8
> Reporter: Alex Soto
>
> A factory component fails to reactive after the configuration changes.
> Initially, the component initializes normally. After it is in Active state,
> the configuration referenced by the component _configurationPid_ changes,
> which causes the component to not activate again.
> A minimal application demonstrating this behavior is available here:
> https://github.com/lexsoto/blueprint-ds-config-reload
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
