if you create a factory configuration and anybody takes a peek before you've
had a chance to update, your pudding is trapped forever
------------------------------------------------------------------------------------------------------------------------------------
Key: FELIX-2888
URL: https://issues.apache.org/jira/browse/FELIX-2888
Project: Felix
Issue Type: Bug
Components: Configuration Admin
Affects Versions: configadmin-1.2.8
Environment: Ubuntu 10.04
Reporter: jamie campbell
Priority: Minor
If you create a factory configuration and then one of your bundle comrades (or
another internal class) has a peek to see if there's anything ready yet, the
original code that created the factory configuration is locked out because the
peeker triggers a cache of a NEW configuration.
Here's the sequence
1)
Userside -> call createFactoryConfiguration and catch the return value so you
can do an update with it
felix side -> creates the configuration but doesn't cache it
2)
Userside -> let your friends know about the pid which they can peek at for
future reference. One of your friends is excited and peeks immediately (or
soon after being informed).
felix side -> since an update hasn't been done yet, it creates a new
configuration and puts it in cache
3)
Userside -> The code that called createFactoryConfiguration finishes its
pondering and is ready to call conf.update(props) .. it gets no exception from
the void method and so carries on with life.
felix side -> The cache already has something in it for this pid, so updates to
the generated conf no longer have any effect, so the caller of
createFactoryConfiguration's assumptions of update success are erroneous
4)
Userside -> Someone does listConfigurations, and doesn't see this conf
felix side -> This is because the system still believes that the configuration
has no properties
It's also useful to note that it is NOT a workaround to simply kludge things by
doing a config regrab immediately before doing the update(props) operation
because the config generated and cached by the peek call was NOT a factory
configuration, because getConfiguration() had no reason to believe it should
autogenerate a factory config, so it autogenerates a normal one.
I think (but am not totally sure) that this may have been a regression from
FELIX-612
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
