You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by "Basmajian, Raffi" <rb...@ofiglobal.com> on 2015/09/23 19:59:07 UTC
Emulating config:edit/update behavior using JMX
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.
Re: Emulating config:edit/update behavior using JMX
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Yes. If you have the Configuration PID, you can check and update
configuration using the ConfigurationAdmin service.
Regards
JB
On 10/19/2015 02:56 PM, Basmajian, Raffi wrote:
> Thank you, JB!
>
> So with this code, it's possible to create a bundle service for the sole purpose of updating configuration of other bundles provided I have their pid, correct?
>
> Raffi
>
> -----Original Message-----
> From: Jean-Baptiste Onofré [mailto:jb@nanthrax.net]
> Sent: Monday, October 19, 2015 8:46 AM
> To: user@karaf.apache.org
> Subject: Re: Emulating config:edit/update behavior using JMX [ EXTERNAL ]
>
> Hi Raffi,
>
> sorry I forgot you, shame on me.
>
> Here's a quick snippet using ConfigAdmin (in a bundle):
>
> ServiceReference ref =
> bundleContext.getServiceReference(ConfigurationAdmin.class);
> if (ref != null) {
> ConfigurationAdmin configAdmin = (ConfigurationAdmin) bundleContext.getService(ref);
> if (configAdmin != null) {
> Configuration config = configAdmin.getConfiguration(pid, null);
> Dictionary properties = config.getProperties();
> // get/set config properties
> }
> }
>
> Regards
> JB
>
> On 10/19/2015 02:39 PM, Basmajian, Raffi wrote:
>> JB,
>>
>> Did you ever get around to this example? I could use one!
>>
>> Best
>> Raffi
>>
>> -----Original Message-----
>> From: Basmajian, Raffi
>> Sent: Thursday, September 24, 2015 9:13 AM
>> To: user@karaf.apache.org
>> Subject: RE: Emulating config:edit/update behavior using JMX [
>> EXTERNAL ]
>>
>> Thank you, Jean, look forward to seeing the example!
>>
>> -----Original Message-----
>> From: Jean-Baptiste Onofré [mailto:jb@nanthrax.net]
>> Sent: Wednesday, September 23, 2015 3:34 PM
>> To: user@karaf.apache.org
>> 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:jb@nanthrax.net]
>>> Sent: Wednesday, September 23, 2015 2:49 PM
>>> To: user@karaf.apache.org
>>> 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é
>>> jbonofre@apache.org
>>> 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é
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
RE: Emulating config:edit/update behavior using JMX
Posted by "Basmajian, Raffi" <rb...@ofiglobal.com>.
Thank you, JB!
So with this code, it's possible to create a bundle service for the sole purpose of updating configuration of other bundles provided I have their pid, correct?
Raffi
-----Original Message-----
From: Jean-Baptiste Onofré [mailto:jb@nanthrax.net]
Sent: Monday, October 19, 2015 8:46 AM
To: user@karaf.apache.org
Subject: Re: Emulating config:edit/update behavior using JMX [ EXTERNAL ]
Hi Raffi,
sorry I forgot you, shame on me.
Here's a quick snippet using ConfigAdmin (in a bundle):
ServiceReference ref =
bundleContext.getServiceReference(ConfigurationAdmin.class);
if (ref != null) {
ConfigurationAdmin configAdmin = (ConfigurationAdmin) bundleContext.getService(ref);
if (configAdmin != null) {
Configuration config = configAdmin.getConfiguration(pid, null);
Dictionary properties = config.getProperties();
// get/set config properties
}
}
Regards
JB
On 10/19/2015 02:39 PM, Basmajian, Raffi wrote:
> JB,
>
> Did you ever get around to this example? I could use one!
>
> Best
> Raffi
>
> -----Original Message-----
> From: Basmajian, Raffi
> Sent: Thursday, September 24, 2015 9:13 AM
> To: user@karaf.apache.org
> Subject: RE: Emulating config:edit/update behavior using JMX [
> EXTERNAL ]
>
> Thank you, Jean, look forward to seeing the example!
>
> -----Original Message-----
> From: Jean-Baptiste Onofré [mailto:jb@nanthrax.net]
> Sent: Wednesday, September 23, 2015 3:34 PM
> To: user@karaf.apache.org
> 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:jb@nanthrax.net]
>> Sent: Wednesday, September 23, 2015 2:49 PM
>> To: user@karaf.apache.org
>> 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é
>> jbonofre@apache.org
>> 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é
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Emulating config:edit/update behavior using JMX
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Raffi,
sorry I forgot you, shame on me.
Here's a quick snippet using ConfigAdmin (in a bundle):
ServiceReference ref =
bundleContext.getServiceReference(ConfigurationAdmin.class);
if (ref != null) {
ConfigurationAdmin configAdmin = (ConfigurationAdmin)
bundleContext.getService(ref);
if (configAdmin != null) {
Configuration config = configAdmin.getConfiguration(pid, null);
Dictionary properties = config.getProperties();
// get/set config properties
}
}
Regards
JB
On 10/19/2015 02:39 PM, Basmajian, Raffi wrote:
> JB,
>
> Did you ever get around to this example? I could use one!
>
> Best
> Raffi
>
> -----Original Message-----
> From: Basmajian, Raffi
> Sent: Thursday, September 24, 2015 9:13 AM
> To: user@karaf.apache.org
> Subject: RE: Emulating config:edit/update behavior using JMX [ EXTERNAL ]
>
> Thank you, Jean, look forward to seeing the example!
>
> -----Original Message-----
> From: Jean-Baptiste Onofré [mailto:jb@nanthrax.net]
> Sent: Wednesday, September 23, 2015 3:34 PM
> To: user@karaf.apache.org
> 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:jb@nanthrax.net]
>> Sent: Wednesday, September 23, 2015 2:49 PM
>> To: user@karaf.apache.org
>> 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é
>> jbonofre@apache.org
>> 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é
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
RE: Emulating config:edit/update behavior using JMX
Posted by "Basmajian, Raffi" <rb...@ofiglobal.com>.
JB,
Did you ever get around to this example? I could use one!
Best
Raffi
-----Original Message-----
From: Basmajian, Raffi
Sent: Thursday, September 24, 2015 9:13 AM
To: user@karaf.apache.org
Subject: RE: Emulating config:edit/update behavior using JMX [ EXTERNAL ]
Thank you, Jean, look forward to seeing the example!
-----Original Message-----
From: Jean-Baptiste Onofré [mailto:jb@nanthrax.net]
Sent: Wednesday, September 23, 2015 3:34 PM
To: user@karaf.apache.org
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:jb@nanthrax.net]
> Sent: Wednesday, September 23, 2015 2:49 PM
> To: user@karaf.apache.org
> 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é
> jbonofre@apache.org
> 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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
RE: Emulating config:edit/update behavior using JMX
Posted by "Basmajian, Raffi" <rb...@ofiglobal.com>.
Thank you, Jean, look forward to seeing the example!
-----Original Message-----
From: Jean-Baptiste Onofré [mailto:jb@nanthrax.net]
Sent: Wednesday, September 23, 2015 3:34 PM
To: user@karaf.apache.org
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:jb@nanthrax.net]
> Sent: Wednesday, September 23, 2015 2:49 PM
> To: user@karaf.apache.org
> 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é
> jbonofre@apache.org
> 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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Emulating config:edit/update behavior using JMX
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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:jb@nanthrax.net]
> Sent: Wednesday, September 23, 2015 2:49 PM
> To: user@karaf.apache.org
> 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é
> jbonofre@apache.org
> 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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
RE: Emulating config:edit/update behavior using JMX
Posted by "Basmajian, Raffi" <rb...@ofiglobal.com>.
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:jb@nanthrax.net]
Sent: Wednesday, September 23, 2015 2:49 PM
To: user@karaf.apache.org
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é
jbonofre@apache.org
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.
Re: Emulating config:edit/update behavior using JMX
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com