Mailing-List: contact issues-help@karaf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@karaf.apache.org
Date: Mon, 9 Apr 2012 09:31:21 +0000 (UTC)
From: "Jamie goodyear (Closed) (JIRA)" <jira@apache.org>
To: issues@karaf.apache.org
Message-ID: 
 <117425472.2178.1333963881384.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1612943517.3276.1330530118477.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Closed] (KARAF-1243) Karaf JMX Config MBean behaves in
 unpredictable ways
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/KARAF-1243?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jamie goodyear closed KARAF-1243.
---------------------------------

   =20
> Karaf JMX Config MBean behaves in unpredictable ways
> ----------------------------------------------------
>
>                 Key: KARAF-1243
>                 URL: https://issues.apache.org/jira/browse/KARAF-1243
>             Project: Karaf
>          Issue Type: Bug
>          Components: karaf-config
>    Affects Versions: 2.2.5
>            Reporter: J=C3=BCrgen Kindler
>            Assignee: Christian Schneider
>            Priority: Critical
>             Fix For: 2.2.6, 3.0.0
>
>         Attachments: KarafConfigMBeanTest.zip, karaf2.2.x-config.patch
>
>
> Although the API of the Karaf Config MBean looks like it offers synchrono=
us calls, in reality
> this is not true. I ran into some issues with this, because I tried to in=
stall configurations
> for bundles to be picked up (see attached maven test case project to be u=
sed with a default running
> Karaf 2.2.5 container)
> It seems that the config bundle may need quite a long time to finish appl=
ying the configuration
> changes, but returns BEFORE this is finished in background.
> I have searched around, dug through code, but found no way to determine a=
t which time I can
> safely assume that a configuration change is finished and I can continue =
with installing the bundle
> that may pick up this configuration (in some cases the default configurat=
ion is enough, but more=20
> often I want to override that...). So I finally ended up with polling for=
 the configuration changes,
> but even that sometimes fails and I could loop infinitely and get no resu=
lt (got an empty Map from proplist method).
> From the JavaDoc of the MBean I would - as said - expect that I do not ha=
ve to do that, but could
> assume that after a create or propset call returns, the configuration is =
active. I would have been
> a bit happier, if the config MBean offered JMX events that notify about t=
he completion of a=20
> configuration change, but after digging deeper it seems that even that wo=
uld not be an optimal solution.
> From my understanding the underlying implementation is a mix of Karaf mai=
ntaining its own config
> files inside the etc folder plus updating data inside the OSGi ConfigAdmi=
n Service.
> The good thing about the console commands is that they implement a strate=
gy that really
> matches the idea of the OSGi ConfigAdmin service (the service always publ=
ishes complete configurations
> as Dictionary instances). So on the console the config commands maintain =
state between config:edit=20
> and config:update. Sending off config:update will publish all collected c=
hanges as one configuration
> instance.
> The API on the JMX level was more or less directly derived from the way t=
he config console commands
> work, but tries to avoid maintaining state - so there's no equivalent to =
config:edit / config:update.
> Instead, propset, propdel and propappend immediately trigger propagation =
of simple changes to the
> configuration. So on JMX level the granularity is not sending of a new Di=
ctionary instance, but=20
> reflects the operations to create such an instance. Instead of publishing=
 one change a configuration
> containing 20 properties would trigger 20 changes.=20
> This will also cause multiple notifications for any "interested" configur=
ation change listener ...=20
> resulting not only in more load, but also possibly in inconsistent config=
uration sub stages to cope
> with: Imagine a service requires two configuration parameters to work cor=
rectly. Instead of getting
> one configuration notification that contains the two parameters, it will =
get two notifications and thus will have to handle the case that the second=
 parameter is missing (desperately hoping that sooner or later this second =
parameter will appear ...).
> Phew ':-) ... so I would suggest that this API should be changed:
> - guarantee that on return from an MBean method that changes a configurat=
ion, this configuration=20
>   can be assumed to be active (so after creating a query call will return=
 the equivalent created config).
> - if this appears to be impossible, the bean should at least provide JMX =
events a client can listen
>   to in order to be notified when a configuration call is finished.
> - in order to play nicely inside the OSGi framework, it should be possibl=
e to create configurations
>   by calling void create(String pid, Map<String, String> config)
> - propset / propappend / propdel should be deprecated or (better) directl=
y removed. (They make sense
>   on console, but not for JMX).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira