Cetra Free created KARAF-5843:
---------------------------------

             Summary: Programmatically Created Configs are not persisted in 
`karaf.etc`
                 Key: KARAF-5843
                 URL: https://issues.apache.org/jira/browse/KARAF-5843
             Project: Karaf
          Issue Type: Bug
          Components: karaf-config
    Affects Versions: 4.1.5
            Reporter: Cetra Free


When using OSGi's ConfigurationAdmin via a blueprint bean, it doesn't save the 
configuration in the `etc` directory if the file doesn't exist before calling 
{{update(props)}}. 

Rather it saves it in the file cache.

I.e, if I update a config of `com.example.config` I'd expect that to be 
persisted in the following location:
{code:java}
etc/com.example.config.cfg
{code}


Instead, I see it in this location:
{code:java}
data/cache/bundle8/data/config/com/example/config.config
{code}

If the file exists in the location beforehand, this appears to work OK.

Example blueprint:

{code:xml}
<reference id="configurationAdmin" 
interface="org.osgi.service.cm.ConfigurationAdmin"/>
<bean id="persistCheck" class="com.example.PersistCheck" init-method=" init" >
    <property name="configurationAdmin" ref="configurationAdmin" />
</bean>
{code}


Example Java Class:

{code:java}
import org.osgi.service.cm.Configuration;
import org.osgi.service.cm.ConfigurationAdmin;

import java.io.IOException;
import java.util.Dictionary;
import java.util.Hashtable;

public class PersistCheck {

    public ConfigurationAdmin getConfigurationAdmin() {
        return configurationAdmin;
    }

    public void setConfigurationAdmin(ConfigurationAdmin configurationAdmin) {
        this.configurationAdmin = configurationAdmin;
    }

    ConfigurationAdmin configurationAdmin;

    public void init() throws IOException {

        Configuration configuration = 
configurationAdmin.getConfiguration("com.example.config", "?");
        Dictionary<String, Object> props = new Hashtable<>();
        configuration.update(props);

    }

}
{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to