[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] ConfigAdmin getConfiguration from external storage

Actually we need a pull mechanism in addition to the push mechanism currently implemented by the Config Admin. This pull mechanism should allow the call to getConfiguration to end in a custom component, which will return the configuration from custom storage, based on the calling context. Any caching of these configurations in the ConfigAdmin service will break our scenario. I am not sure that this is achievable only with a change in the implementation of the Config Admin, without changes in the API too. If you think that it is achievable with changes only in implementation, I will open a bug for feature request.

 

Lazar

 

From: equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Thomas Watson
Sent: Wednesday, May 25, 2011 3:31 PM
To: Equinox development mailing list
Subject: Re: [equinox-dev] ConfigAdmin getConfiguration from external storage

 

I'm not sure I understand how this would work. Would you designate particular PIDs as being global vs. component-specific configurations? Either way the Equinox Configuration Admin implementation would need to be enhanced to allow a different persistence mechanism/policy to be plugged in. Instead of forking or writing your own implementation I suggest you open a bug report so we can discuss an enhancement and possible ways of implementing it.

Tom



Inactive hide details for "Kirchev, Lazar" ---05/25/2011 06:44:11 AM---Hello,"Kirchev, Lazar" ---05/25/2011 06:44:11 AM---Hello,


From:


"Kirchev, Lazar" <l.kirchev@xxxxxxx>


To:


Equinox development mailing list <equinox-dev@xxxxxxxxxxx>


Date:


05/25/2011 06:44 AM


Subject:


Re: [equinox-dev] ConfigAdmin getConfiguration from external storage





Hello,

What we actually need is to be able to use a custom configuration storage along with the ConfigAdmin's internal storage, without moving configurations from the custom storage to the internal storage. The goal is to use the ConfigAdmin's internal storage for global configurations, while the custom storage for more component-specific configurations. Both have nothing in common and should not be mixed up. We want to use the Equinox implementation of ConfigAdmin, without forking the code or reimplementing it. Could you propose a way to achieve this?

Regards,
Lazar

-----Original Message-----
From: equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Neil Bartlett
Sent: Friday, May 13, 2011 3:29 PM
To: Equinox development mailing list
Subject: Re: [equinox-dev] ConfigAdmin getConfiguration from external storage

Hi Philip,

The normal way to hook config admin into an external data storage is
to write a management agent that *calls* getConfiguration() and
supplies the data via an update to the Configuration object. That way
your agent can work with any config admin implementation.

Typically config admin implementations use their own internal storage
area for persistence. If you want to customise that internal storage
then you may need to write your own implementation (though I think at
least the Felix implementation has an extension mechanism so you don't
have to write the whole thing).

Regards,
Neil

On Fri, May 13, 2011 at 12:43 PM, Philip Yankov <duxmaster@xxxxxxxxx> wrote:
> Hi,
>
> Is it possible to get a notification when
> ConfigurationAdmin.getConfiguration( with any pid ) is called and return a
> configuration from an external storage then? Are you aware of existing
> mechanism to achieve this? Alternatively, we thought of pluging a hook
> inside getConfiguration() method, or directly extending
> ConfigurationAdminImpl and registering it instead of the current service
> (ConfigurationAdminImpl should be made public though). How do you think,
> what would be the preferred approach?
>
> Best regards,
>   Philip Yankov
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

GIF image

PNG image

PNG image