You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Andrei Pozolotin <an...@gmail.com> on 2011/06/05 07:49:21 UTC
ConfigurationAdmin & SCR component self-update
Hello.
I am using felix ConfigurationAdmin & SCR;
question: how can I combine ConfigurationAdmin & component self-update?
for example, SCR component has a ui located on the screen (x,y);
this is pushed from ConfigurationAdmin to the component via
SCR.activate() & SCR.modified();
now user moves a ui to a new (x,y); per osgi spec, ConfigurationAdmin
does not differentiate on the update request source;
hence, Configuration.update(properties) (trying to persist the new
(x,y))
if called from configuration target component itself,
will create a recursion, which it does;
and Configuration.update() /* with no properties*/ does not create a
recursion,
but does not persist the configuration either;
what am I missing? :-)
Thank you,
Andrei.
Re: ConfigurationAdmin & SCR component self-update
Posted by Felix Meschberger <fm...@adobe.com>.
Hi Andrei,
Am Sonntag, den 05.06.2011, 16:08 +0100 schrieb Andrei Pozolotin:
> Felix:
> -------- Original Message --------
> Subject: Re: ConfigurationAdmin & SCR component self-update
> From: Felix Meschberger <fm...@adobe.com>
> To: users@felix.apache.org <us...@felix.apache.org>
> Date: Sun 05 Jun 2011 07:41:28 AM CDT
> > Hi,
> >
> > Am Sonntag, den 05.06.2011, 06:49 +0100 schrieb Andrei Pozolotin:
> >
> >> what am I missing? :-)
> >>
> >
> > It is under your own control to break the recursion: Your component will
> > only have to call Configuration Admin configuration if such
> > configuration is not provided through the activate or modify method,
> > i.e. only if such update is induced externally.
> >
> yes, this is what I came up with. it just feels odd there is no way to do
> Configuration.update(...) which does persist only but does not propagate
> to SCR.
This is how the two service are specified:
Configuration.udate(Dictionary) must persist, update
ManagedService[Factory] services and send events to listsners.
SCR must forward configuration to components (unless the component is
configurationPolicy=ignore).
In your example, though, SCR was not involved at all, since your
component implemented a ManagedService which is called by
ConfigurationAdmin after update().
Regards
Felix
> > BTW: for your sample use case of UI location you might want to look into
> > the OSGi Preferences Service specification which sounds more appropriate
> > for such configuration (which generally is different per user).
> >
> great idea. looking into it now.
> > Regards
> > Felix
> >
> thank you.
>
> Andrei.
> > Regards
> > Felix
> >
> >
> >> Thank you,
> >>
> >> Andrei.
> >>
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: ConfigurationAdmin & SCR component self-update
Posted by Andrei Pozolotin <an...@gmail.com>.
Felix:
-------- Original Message --------
Subject: Re: ConfigurationAdmin & SCR component self-update
From: Felix Meschberger <fm...@adobe.com>
To: users@felix.apache.org <us...@felix.apache.org>
Date: Sun 05 Jun 2011 07:41:28 AM CDT
> Hi,
>
> Am Sonntag, den 05.06.2011, 06:49 +0100 schrieb Andrei Pozolotin:
>
>> what am I missing? :-)
>>
>
> It is under your own control to break the recursion: Your component will
> only have to call Configuration Admin configuration if such
> configuration is not provided through the activate or modify method,
> i.e. only if such update is induced externally.
>
yes, this is what I came up with. it just feels odd there is no way to do
Configuration.update(...) which does persist only but does not propagate
to SCR.
> BTW: for your sample use case of UI location you might want to look into
> the OSGi Preferences Service specification which sounds more appropriate
> for such configuration (which generally is different per user).
>
great idea. looking into it now.
> Regards
> Felix
>
thank you.
Andrei.
> Regards
> Felix
>
>
>> Thank you,
>>
>> Andrei.
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
Re: ConfigurationAdmin & SCR component self-update
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am Sonntag, den 05.06.2011, 06:49 +0100 schrieb Andrei Pozolotin:
> Hello.
>
> I am using felix ConfigurationAdmin & SCR;
>
> question: how can I combine ConfigurationAdmin & component self-update?
>
> for example, SCR component has a ui located on the screen (x,y);
> this is pushed from ConfigurationAdmin to the component via
> SCR.activate() & SCR.modified();
>
> now user moves a ui to a new (x,y); per osgi spec, ConfigurationAdmin
> does not differentiate on the update request source;
>
> hence, Configuration.update(properties) (trying to persist the new
> (x,y))
> if called from configuration target component itself,
> will create a recursion, which it does;
>
> and Configuration.update() /* with no properties*/ does not create a
> recursion,
> but does not persist the configuration either;
>
> what am I missing? :-)
It is under your own control to break the recursion: Your component will
only have to call Configuration Admin configuration if such
configuration is not provided through the activate or modify method,
i.e. only if such update is induced externally.
BTW: for your sample use case of UI location you might want to look into
the OSGi Preferences Service specification which sounds more appropriate
for such configuration (which generally is different per user).
Regards
Felix
Regards
Felix
>
> Thank you,
>
> Andrei.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: ConfigurationAdmin & SCR component self-update
Posted by Andrei Pozolotin <an...@gmail.com>.
Peter:
makes perfect sense; thank you.
Andrei
-------- Original Message --------
Subject: Re: ConfigurationAdmin & SCR component self-update
From: Peter Kriens <pe...@aqute.biz>
To: users@felix.apache.org
Date: Wed 08 Jun 2011 07:51:25 AM CDT
> The basic idea is that when the user updates the window position the code just updates the Configuration and not the screen. This will result a call in modified that contains the new coordinates, which are then used to reposition the window.
>
> This way you have only one code path for the initial start and any updates. Clean and simple.
>
> Of course you should not do this for fine grained updates but for courser configuration that is the approach: update config -> use the notification to reflect the update.
>
> Kind regards,
>
> Peter Kriens
>
>
>
> On 5 jun 2011, at 07:49, Andrei Pozolotin wrote:
>
>
>> Hello.
>>
>> I am using felix ConfigurationAdmin & SCR;
>>
>> question: how can I combine ConfigurationAdmin & component self-update?
>>
>> for example, SCR component has a ui located on the screen (x,y);
>> this is pushed from ConfigurationAdmin to the component via
>> SCR.activate() & SCR.modified();
>>
>> now user moves a ui to a new (x,y); per osgi spec, ConfigurationAdmin
>> does not differentiate on the update request source;
>>
>> hence, Configuration.update(properties) (trying to persist the new
>> (x,y))
>> if called from configuration target component itself,
>> will create a recursion, which it does;
>>
>> and Configuration.update() /* with no properties*/ does not create a
>> recursion,
>> but does not persist the configuration either;
>>
>> what am I missing? :-)
>>
>> Thank you,
>>
>> Andrei.
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
Re: ConfigurationAdmin & SCR component self-update
Posted by Peter Kriens <pe...@aqute.biz>.
The basic idea is that when the user updates the window position the code just updates the Configuration and not the screen. This will result a call in modified that contains the new coordinates, which are then used to reposition the window.
This way you have only one code path for the initial start and any updates. Clean and simple.
Of course you should not do this for fine grained updates but for courser configuration that is the approach: update config -> use the notification to reflect the update.
Kind regards,
Peter Kriens
On 5 jun 2011, at 07:49, Andrei Pozolotin wrote:
> Hello.
>
> I am using felix ConfigurationAdmin & SCR;
>
> question: how can I combine ConfigurationAdmin & component self-update?
>
> for example, SCR component has a ui located on the screen (x,y);
> this is pushed from ConfigurationAdmin to the component via
> SCR.activate() & SCR.modified();
>
> now user moves a ui to a new (x,y); per osgi spec, ConfigurationAdmin
> does not differentiate on the update request source;
>
> hence, Configuration.update(properties) (trying to persist the new
> (x,y))
> if called from configuration target component itself,
> will create a recursion, which it does;
>
> and Configuration.update() /* with no properties*/ does not create a
> recursion,
> but does not persist the configuration either;
>
> what am I missing? :-)
>
> Thank you,
>
> Andrei.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org