[
https://issues.apache.org/jira/browse/FELIX-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger resolved FELIX-2888.
--------------------------------------
Resolution: Fixed
Fix Version/s: configadmin-1.4.0
Assignee: Felix Meschberger
Fixed in Rev. 1244978
Configuration retrieved through getConfiguration now also includes factory
configuration which has not been persisted yet.
Also configuration retrieved from getConfiguration is always persisted (even
new factory configuration not updated yet). This is to comply with the
getConfiguration contract.
> 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
> Assignee: Felix Meschberger
> Priority: Minor
> Fix For: configadmin-1.4.0
>
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
