[
https://issues.apache.org/jira/browse/FELIX-4698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14221488#comment-14221488
]
David Jencks commented on FELIX-4698:
-------------------------------------
It's been quite a while since I looked at this area, and I haven't consulted
the specs right now either. I _thought_ (but have not verified) that config
admin had to make sure an update event was processed before it could issue a
delete event on the same configuration. If so, I think the problem occurs when
we read a configuration directly for a new component (i.e. not prompted by a
config event) and someone deletes the config at the same time. In this case I
think the correct action would be to ignore the delete event (on the event
thread) and treat the configuration as deleted on the thread that got the
illegalStateException. Alternatively we might need to write a
ConfigurationTracker-like thing similar to ServiceTracker: ServiceTracker
solves this problem for services.
If config admin doesn't have to keep the events for a single configuration in
order, I'm not sure what other problems we'll have to deal with.
Which spec did you check and what section did you find that is relevant?
> SynchronousConfigurationListener
> --------------------------------
>
> Key: FELIX-4698
> URL: https://issues.apache.org/jira/browse/FELIX-4698
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.8.2
> Reporter: Jens Offenbach
> Labels: configuration, configurationadmin, scr
>
> When you directly create/update a configuration and delete it right after
> creation, the component instance creation of components which preconditions
> become fulfilled (using ConfigurationPolicy.REQUIRE) often fails. The reason
> is that events from the ConfigurationAdmin are delivered to SCR
> asynchronously. This results in the following behavior: SCR receives a
> configuration update event and accesses e.g. its properties. The call fails
> because the configuration was deleted in the meantime. A solution would be to
> implement SynchronousConfigurationListener in the class CongurationSupport
> instead of ConfigurationListener. That forces the ConfigurationAdmin to
> deliver the update events before someone can delete the configuration.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
