[
https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250455#comment-13250455
]
David Jencks commented on FELIX-3377:
-------------------------------------
I've identified the source of the 3 integration test failures. In rev 1298275
we added to ImmediateComponentManager.deleteComponent a line setting
m_configurationProperties to null. This is wrong. This field should only be
set when confg admin provides an updates set of properties. In particular, for
a component without a modify method, Config Admin calls reconfigured, which
sets m_configurationProperties to the new properties. Then since there's no
modify method the component has to be deleted..... wiping out the
m_componentProperties we just set.... and then recreated.
The trivial patch is
---
a/scr/src/main/java/org/apache/felix/scr/impl/manager/ImmediateComponentManager.java
+++
b/scr/src/main/java/org/apache/felix/scr/impl/manager/ImmediateComponentManager.java
@@ -141,7 +141,6 @@ public class ImmediateComponentManager extends
AbstractComponentManager
m_componentContext = null;
m_properties = null;
m_propertiesOverwrite = null;
- m_configurationProperties = null;
}
> Allow a component to update its own service properties
> ------------------------------------------------------
>
> Key: FELIX-3377
> URL: https://issues.apache.org/jira/browse/FELIX-3377
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.0
> Reporter: David Jencks
> Attachments: FELIX-3377-2.diff, FELIX-3377-3.diff, FELIX-3377.diff
>
>
> If you just register a service in code, you can give the ServiceRegistration
> to the service and it can update its service properties to reflect what it
> can discover about its environment. This proposes that services registered
> through DS should be able to do this too, by calling an
> updateProperties(Dictionary) method on the ComponentContext. (Since we'd
> need a spec update to add the method to ComponentContext, I added a new
> interface that ComponentContextImpl implements).
> Right now a service could get Config Admin and modify the properties there,
> but then (a) the update method is called even though the component itself
> initiated the changes and (b) the new property values are persisted which is
> presumably not desired.
> According to the spec config admin properties override default property
> values specified in the component xml. I think that in order to reduce
> confusion, once a property has been set through config admin it should not be
> possible to update it through this update method. This also makes
> implementing this idea easy.
> IIUC this idea does not make sense for component factories.
> This idea was originally suggested by Erin Schnabel in OSGI bug 2250.
--
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
