[
https://issues.apache.org/jira/browse/FELIX-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15879147#comment-15879147
]
David Jencks commented on FELIX-5549:
-------------------------------------
I continue to think that trying to communicate about this in english is too
imprecise to result in confidence that either of us is understanding the other.
CompnentFactory is a service registered by ds, not a component. When you call
newInstance that generates a component, which, without a modified method, will
be destroyed if you change the configuration. The ComponentFactory service
shouldn't be affected in any visible way by changing the configuration.
Some of what you've written seems to indicate that the ComponentFactory service
is unregistered when you change the configuration, but you haven't shown the
log output showing that, and I think the felix integration test indicates that
it isn't. So far I'm working on the idea that it's not affected and we're not
communicating clearly.
Out of curiosity I'd like to know what circumstances you have that lead you to
try using a factory component rather than a normal component with a factory
configuration.
If you need a factory component to respond to configuration changes without
being destroyed, add a modified method. If there are required references that
might not always be present, whenever they become unavailable the components
will be destroyed and not automatically recreated (and if they aren't available
when you call newInstance you'll get an exception).
If you need a "factory" component to have a reasonable lifecycle, the same as a
normal component, use the felix extension I mentioned. This is especially
useful when required references may or may not be present.
I think the reason for this odd lifecycle is the idea that you can get the
single instance from the ComponentInstance and it will never change. So after
it's become deactivated that one obviously can't be used any more. If the idea
had been that you kept the ComponentInstance around and any time you wanted the
instance you got the current object from Componentinstance and didn't cache it
perhaps more useful semantic behavior would be in the spec.
> 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)
