Thank you, Jean, look forward to seeing the example! -----Original Message----- From: Jean-Baptiste Onofré [mailto:[email protected]] Sent: Wednesday, September 23, 2015 3:34 PM To: [email protected] Subject: Re: Emulating config:edit/update behavior using JMX [ EXTERNAL ] Importance: High
You retrieve the ConfigurationAdmin service (using bundleContext.getService()). Using the ConfigurationAdmin service, you can access to a Config PID (getConfiguration(pid, null)) and after the properties in the Config. Let me prepare an example for you. Regards JB On 09/23/2015 08:52 PM, Basmajian, Raffi wrote: > Hi Jean, > > Thanks for the quick reply, > > Is there an example showing how to use ConfigAdmin locally? How is that > achieved? > > Best > Raffi > > -----Original Message----- > From: Jean-Baptiste Onofré [mailto:[email protected]] > Sent: Wednesday, September 23, 2015 2:49 PM > To: [email protected] > Subject: Re: Emulating config:edit/update behavior using JMX [ > EXTERNAL ] > Importance: High > > Hi, > > The "session" is the console shell memory session: it's not available on JMX > as we don't have a memory session or state. > That's why we introduce the update() operation with a map. > > I can merge the change on karaf-2.x branch (2.4.x). > > On the other hand, you can use ConfigAdmin directly (but not remote or by > JMX, only locally). Basically the JMX layer is on top of ConfigAdmin. > > Regards > JB > > On 09/23/2015 07:59 PM, Basmajian, Raffi wrote: >> Hello, >> >> I'm creating a custom tool for managing Karaf /etc configs using >> Karaf 2.4.0/JBoss Fuse 6.2/Java 8/Win7x64. My goal is to emulate >> config:edit/update behavior such that all config changes for the same >> PID are committed atomically, or not at all. >> >> The Karaf CLI supports configuration "sessions", config:edit opens a >> session, and config:update flushes changes to the service. This >> behavior makes sense since - for our use cases -- configuration >> parameters depend on other parameters. >> >> Our automation tool needs programmatic access to manage configuration >> changes, ideally JMX. >> >> After playing around with JMX bean "org.apache.karaf.config/root" and >> its operations (propset/append/setProperty()), the behavior observed >> is not consistent with config:edit/update. Individual changes are >> propagated immediately, causing the service to reload. This is far >> from ideal and does not meet our requirements. >> >> After searching around for solutions, we found this issue which is >> more/less identical to ours: >> https://issues.apache.org/jira/browse/KARAF-1243. >> >> The fix for that issue introduced a new JMX method "update(String >> pid, Map props)" to ConfigMBean, perfect for our needs, but not >> available in 2.4. >> >> What are my options to achieve programmatic configuration management >> for arbitrary bundles while controlling propagation of updates? >> >> Can I use the ConfigurationAdmin service directly? If so, is it >> available from JMX? >> >> I can't upgrade to Karaf 3.0 since Fuse 6.2 depends on Karaf 2.4; is >> it possible to patch 2.4 with fix from KARAF-1243? >> >> Thank you, >> >> Raffi >> >> This e-mail transmission may contain information that is proprietary, >> privileged and/or confidential and is intended exclusively for the >> person(s) to whom it is addressed. Any use, copying, retention or >> disclosure by any person other than the intended recipient or the >> intended recipient's designees is strictly prohibited. If you are not >> the intended recipient or their designee, please notify the sender >> immediately by return e-mail and delete all copies. OppenheimerFunds >> may, at its sole discretion, monitor, review, retain and/or disclose >> the content of all email communications. > > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com > > This e-mail transmission may contain information that is proprietary, > privileged and/or confidential and is intended exclusively for the person(s) > to whom it is addressed. Any use, copying, retention or disclosure by any > person other than the intended recipient or the intended recipient's > designees is strictly prohibited. If you are not the intended recipient or > their designee, please notify the sender immediately by return e-mail and > delete all copies. OppenheimerFunds may, at its sole discretion, monitor, > review, retain and/or disclose the content of all email communications. > -- Jean-Baptiste Onofré [email protected] http://blog.nanthrax.net Talend - http://www.talend.com
