Hi Jean-Baptiste,
I see.
We would like to separate karaf config (the one in karaf/etc) from our own
config (stored in a separate folder out of karaf install).
We also would like to continue using "config:*" commands which are very
convinient.
As you can see in the karaf code below, the ConfigRepository is injected to
the config:* commands (the ConfigRepositoryImpl actually)
---
package org.apache.karaf.config.command;
import java.util.Dictionary;
import org.apache.karaf.config.core.ConfigRepository;
import org.apache.karaf.shell.api.action.Action;
import org.apache.karaf.shell.api.action.lifecycle.Reference;
import org.apache.karaf.shell.api.console.Session;
/**
* Abstract class from which all commands related to the ConfigurationAdmin
* service should derive.
* This command retrieves a reference to the ConfigurationAdmin service
before
* calling another method to actually process the command.
*/
public abstract class ConfigCommandSupport implements Action {
public static final String PROPERTY_CONFIG_PID = "ConfigCommand.PID";
public static final String PROPERTY_CONFIG_PROPS =
"ConfigCommand.Props";
public static final String PROPERTY_FACTORY = "ConfigCommand.Factory";
@Reference
protected ConfigRepository configRepository;
@Reference
protected Session session;
@Override
public Object execute() throws Exception {
return doExecute();
}
---
Question:
* Is there a way to inject our own ConfigRepository implementation here
then?
* I have the feeling that the pluggability of other backend support is not
available yet?
It would be great to be able to route pid storage based on their names
(using configuration).
Example:
foo.bar.* => database storage
org.apache.karaf.* => use file storage
com.acme.* => use LDAP
etc..
Thanks
Christian
On Mon, Mar 20, 2017 at 2:37 PM, Jean-Baptiste Onofré <[email protected]>
wrote:
> Hi Christian,
>
> You can always specific another value for karaf.etc variable.
>
> It's also possible that you instanciate ConfigRepository with different
> constructor args.
>
> However, for convenience, we can introduce a karaf.cfg.storage variable or
> so.
>
> The purpose of the ConfigRepository is to be able to plug other backend to
> store the cfg (like database, LDAP, ...).
>
> Regards
> JB
>
>
> On 03/20/2017 02:27 PM, Christian Wolf wrote:
>
>> Hi all,
>>
>> Having a look at the implementation of the karaf config:* commands, I
>> noticed
>> that pid storage is actually managed by
>> org.apache.karaf.config.core.ConfigRepository
>>
>> The ConfigRepositoryImpl is instanciated as follow in karaf:
>>
>> * ConfigRepository configRepository = new
>> ConfigRepositoryImpl(configurationAdmin, new
>> File(System.getProperty("karaf.etc")));
>>
>> This explains why setting new configuration with config:* commands (.cfg
>> file
>> does not exist before) always creates <pid>.cfg under the "kara.etc"
>> folder.
>>
>> Two improvements around ConfigAdmin have been suggested in
>> "https://issues.apache.org/jira/browse/KARAF-888"
>>
>> * we could create a Karaf Config Service on top of ConfigAdmin to be able
>> to
>> choose and change the storage backend of configuration. For instance,
>> replace/concats the etc folder with a JDBC or LDAP backend. We could
>> implement
>> something similar to JAAS with a kind of ConfigModule.
>>
>> * the config:* commands shouldn't be responsible to writing the files. The
>> config:* commands could use the Karaf Config Service. The Karaf Config
>> Service
>> will be responsible to updating the ConfigAdmin service, and flush the
>> changes
>> to the storage backend.
>>
>>
>> Question:
>> As described in my first email, we would like to exeternalize our
>> configuration
>> in a separate dedicated folder.
>> * Is it currenlty possible (karaf 4.0.8 or higher) to change the storage
>> backend
>> somehow to externalize/route configuration ?
>>
>> (Apparently, with the ConfigRepositoryImpl, new <pid>.cfg files are always
>> created under karaf.etc folder)
>>
>> Thanks
>> Christian
>>
>> On Fri, Mar 17, 2017 at 11:54 AM, Christian Wolf <
>> [email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Hi,
>>
>> I have a question regarding pid configuration files and "config:*"
>> karaf
>> commands.
>>
>> By default, pid configuration file goes here:
>>
>> * karaf/etc/*.cfg
>>
>> I would like to store only our own "foo.bar.*.cfg" pid files in an
>> external
>> folder (somewhere out of the karaf installation) such as:
>>
>> * /home/myuser/product/config/foo.bar.*.cfg
>>
>> My idea was to define this external folder in the
>> "felix.fileinstall.dir"
>> property in "karaf/etc/config.propertes" as follow:
>>
>> #
>> # Configuration FileMonitor properties
>> #
>> felix.fileinstall.enableConfigSave = true
>> felix.fileinstall.dir= /home/myuser/product/config , ${karaf.etc}
>> felix.fileinstall.filter = .*\\.cfg
>> ...
>>
>> If our pid files foo.bar.*.cfg are exising (even as empty file) in
>> /home/myuser/product/config, it is working fine.
>> I mean, we can edit the files either manuall or using the config:edit,
>> config:update commands
>>
>> Now my problem is the following:
>> I do have an scr @Component which becomes active only when
>> configuration is
>> created.
>>
>> So to activate it, I do the following with karaf commands:
>>
>> karaf@root()> config:edit foo.bar.connection
>> karaf@root()> config:property-set url ldap://localhost:389
>> karaf@root()> config:update
>>
>> My component is activated as expected, no problems here.
>>
>> Unfortunately, the foo.bar.connection.cfg pid file is created under
>> ${karaf.etc} instead of /home/myuser/product/config
>>
>> Is there a way to external configuration somehow and ensure that
>> matching
>> pid files are store there?
>>
>> Please note that we are using
>> org.osgi.service.metatype.annotations.ObjectClassDefinition to
>> define our config
>>
>> @ObjectClassDefinition(pid = "foo.bar.connection")
>> public @interface ConnectionConfig {
>> String url() default "http://localhost:8080";
>> }
>>
>> We are currently using karaf 4.0.8.
>>
>> Thanks for help
>> Regards,
>> Christian
>>
>>
>>
>>
>>
> --
> Jean-Baptiste Onofré
> [email protected]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>