[
https://issues.apache.org/jira/browse/FELIX-4698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14217634#comment-14217634
]
Jens Offenbach edited comment on FELIX-4698 at 11/19/14 1:43 PM:
-----------------------------------------------------------------
Yes... You are right, that imitates the problem exactly. SCR calls
getProperties() on an already "deleted" configuration which causes an
IllegalStateException in the Felix ConfigurationAdmin. Things would work, when
the ConfigurationAdmin allows all (async) ConfigurationListeners to access the
configuration (its properties) when it was possible from the point in time of
event creation. A Configuration#delete() must not prevent access to its
internal state, if a listener is notified by a previous event (e.g CM_UPDATED).
I have checked the specification... No hint can be found that targets this
special case. I have also tested it with the Equinox ConfigurationAdmin: The
same problem exists, unfortunately I got no log output. I only thing I see in
SCR is, that nothing happens.
Have you got any idea what we can do to solve the problem without resorting to
SynchronousConfigurationListener?
was (Author: herr-herner):
Yes... You are right, that imitated the problem exactly. SCR calls
getProperties() on an already "deleted" configuration which causes an
IllegalStateException in the Felix ConfigurationAdmin. Things would work, when
the ConfigurationAdmin allows all (async) ConfigurationListeners to access the
configuration (its properties) when it was possible from the point in time of
event creation. A Configuration#delete() must not prevent access to its
internal state, if a listener is notified by a previous event (e.g CM_UPDATED).
I have checked the specification... No hint can be found that targets this
special case. I have also tested it with the Equinox ConfigurationAdmin: The
same problem exists, unfortunately I got no log output. I only thing I see in
SCR is, that nothing happens.
Have you got any idea what we can do to solve the problem without resorting to
SynchronousConfigurationListener?
> 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)
