You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Paul McCulloch <pk...@gmail.com> on 2018/03/22 13:15:05 UTC
Custom PersistenceManager configurations not instantiating components
Hi,
I'm trying to implement a SQL backed Confg Admin persistence mechanism to
handle a subset of Karaf 4.1 configuration. My implementation works for the
most part - configurations are displayed in the web console; new
configurations are stored & retrieved at startup.
However, Services which require a configuration provided by
my PersistenceManager do not have their configuration recognised at startup
& do not get activated.
I believe this is a timing issue. If I save the configuration via the
webconsole after startup then my Service starts. If I change my
PersistenceManager to not require the database service (either a DataSource
or a JPATemplate) & to deliver a hardcoded configuration then my service
starts.
At the moment I have a nasty workaround of having a background thread
update all of my configurations once the PersistenceManager has been called.
Does this sound like a bug? Any hints on a better workaround?
Thanks.
Paul
Re: Custom PersistenceManager configurations not instantiating components
Posted by David Jencks <da...@gmail.com>.
I’m glad it works! FWIW when osgi r7 is available there will be a mechanism for specifying the pid of factory configurations.
David Jencks
Sent from my iPhone
> On Mar 23, 2018, at 9:30 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
> FYI,
>
> We have a staticcm impl in Karaf:
>
> https://github.com/apache/karaf/tree/master/services/staticcm/src/main/java/org/apache/karaf/services/staticcm
>
> We use it in the static profile.
>
> Regards
> JB
>
>> On 03/23/2018 05:23 PM, Paul McCulloch wrote:
>> I reviewed the Felix config admin implementation & it really isn't designed to
>> handle the late addition of new persistence mechanisms. I'll see about getting
>> the docs updated to save other people from going down that route.
>>
>> I've successfully implemented David's suggestion and have a DS component which
>> creates configurations on activation, persists them when the configurations are
>> modified & removes them when deleted. It all seems to work fine.
>>
>> The only minor issue is that factory configurations get a new PID each time they
>> are created (as you can't AFAIK create a factory configuration with a specific
>> PID). This has no impact.
>>
>> Thanks for the guidance.
>>
>> Paul
>>
>> On 22 March 2018 at 23:26, David Jencks <david.a.jencks@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>> A config admin implementation has to have all the preexisting persisted
>> configurations available when the config admin service is registered. If I
>> understand your description of what you implemented, this is not possible
>> with your architecture. I’m suggesting your discard your current approach
>> and write something that interacts with the config admin service as a
>> management agent, i.e. it creates, modifies, and deletes configurations
>> through the config admin api.
>>
>> David Jencks
>>
>> Sent from my iPhone
>>
>> On Mar 22, 2018, at 3:23 PM, Paul McCulloch <pkmcculloch@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>>> Thanks David. I'll try a Felix list, but if you wouldn't mind clarifying
>>> some of what you said I'd be grateful.
>>>
>>> I don't directly create any Configuration instances. I just return an
>>> Enumeration of Dictionary to Felix's config admin which creates
>>> Configurations from this. I don't interact with config admin at all.
>>>
>>> Does that make any difference to your view on what I'm doing?
>>>
>>> Thanks for the idea regarding an alternative design.
>>>
>>> Paul
>>>
>>> http://felix.apache.org/apidocs/configadmin/1.6.0/org/apache/felix/cm/PersistenceManager.html#getDictionaries()
>>> <http://felix.apache.org/apidocs/configadmin/1.6.0/org/apache/felix/cm/PersistenceManager.html#getDictionaries()>
>>>
>>> On 22 March 2018 at 21:40, David Jencks <david.a.jencks@gmail.com
>>> <ma...@gmail.com>> wrote:
>>>
>>> I suspect you are using the Felix config admin so your question more
>>> properly belongs on the Felix lists.
>>>
>>> What you are doing can’t work as is. There are two times an unmodified
>>> configuration is picked up by ds:
>>> 1) when a configurable component is enabled.
>>> 2) when the (Singleton) config admin service is detected by ds.
>>>
>>> Your plan to add an unmodified configuration to config admin after
>>> both these events have occurred won’t result in ds picking up the
>>> configuration. This is correct behavior and I hope you can’t convince
>>> anyone to modify it.
>>>
>>> I suggest instead of breaking the working model of ds plus config
>>> admin you make your auxiliary db persistence create new configurations
>>> when it starts up and delete them when it shuts down. I think you can
>>> then write it as a configuration management agent external to any
>>> particular config admin implementation, and just not worry about the
>>> fact that config admin is also storing the configurations locally.
>>>
>>> David Jencks
>>>
>>> Sent from my iPhone
>>>
>>> On Mar 22, 2018, at 1:30 PM, Paul McCulloch <pkmcculloch@gmail.com
>>> <ma...@gmail.com>> wrote:
>>>
>>>> Thanks for the reply.
>>>>
>>>> The component requiring the configuration that I'm persisting in the
>>>> database is DS. The PersistenceManager is another DS component,
>>>> injected with a JPA template (from Aries JPA). Currently
>>>> my PersistenceManager only manages the configuration for this one
>>>> other component - it delegates storing of all other configurations
>>>> to the standard file based manager.
>>>>
>>>> The config admin service starts early - well before my persistence
>>>> manager is started - but config admin does detect it and use it.
>>>>
>>>> From my debugging efforts it seems that configurations are used to
>>>> satisfy a component at 2 points - when a component bundles is
>>>> started, and when a configuration is created or updated. This works
>>>> fine when the configuration is available before the other component
>>>> (as is the usual case), or when the configuration is created via
>>>> config admin.
>>>>
>>>> The configurations created from the data returned by the
>>>> PersistenceManager don't seem to trigger the relevant operations. A
>>>> PersistenceManager doesn't itself create configurations - it just
>>>> gives the underlying Dictionary to the caller.
>>>>
>>>> As I said, updating the configurations after they have been created
>>>> resolves the issue, as does mocking the PersistenceManager with
>>>> something that can start earlier than my DS component requiring
>>>> configuration. This leads me to believe that the essentials of my
>>>> manager are sound.
>>>>
>>>>
>>>> Paul
>>>>
>>>>
>>>>
>>>> On 22 March 2018 at 19:33, David Jencks <david.a.jencks@gmail.com
>>>> <ma...@gmail.com>> wrote:
>>>>
>>>> I for one don’t understand which components of what kind (ds?
>>>> Blueprint? Hard coded?) are having problems and how the
>>>> components relate. For instance if the dB access for the
>>>> configuration manager relies on a configuration retrieved from
>>>> the dB, I don’t see how you will resolve the circularity. For
>>>> configurations supplied to ds components I would not expect
>>>> problems if the config admin service is registered after the
>>>> persistence layer is fully functional and the config admin is
>>>> fully aware of all the stored configurations. I don’t know if
>>>> blueprint deals well with configurations showing up late, and
>>>> hard coded stuff you would have to deal with yourself.
>>>>
>>>> David Jencks
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Mar 22, 2018, at 6:15 AM, Paul McCulloch
>>>> <pkmcculloch@gmail.com <ma...@gmail.com>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I'm trying to implement a SQL backed Confg Admin persistence
>>>>> mechanism to handle a subset of Karaf 4.1 configuration. My
>>>>> implementation works for the most part - configurations are
>>>>> displayed in the web console; new configurations are stored &
>>>>> retrieved at startup.
>>>>>
>>>>> However, Services which require a configuration provided by
>>>>> my PersistenceManager do not have their configuration recognised
>>>>> at startup & do not get activated.
>>>>>
>>>>> I believe this is a timing issue. If I save the configuration
>>>>> via the webconsole after startup then my Service starts. If I
>>>>> change my PersistenceManager to not require the database service
>>>>> (either a DataSource or a JPATemplate) & to deliver a hardcoded
>>>>> configuration then my service starts.
>>>>>
>>>>> At the moment I have a nasty workaround of having a background
>>>>> thread update all of my configurations once
>>>>> the PersistenceManager has been called.
>>>>>
>>>>> Does this sound like a bug? Any hints on a better workaround?
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Paul
>>>>
>>>>
>>>
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: Custom PersistenceManager configurations not instantiating
components
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
FYI,
We have a staticcm impl in Karaf:
https://github.com/apache/karaf/tree/master/services/staticcm/src/main/java/org/apache/karaf/services/staticcm
We use it in the static profile.
Regards
JB
On 03/23/2018 05:23 PM, Paul McCulloch wrote:
> I reviewed the Felix config admin implementation & it really isn't designed to
> handle the late addition of new persistence mechanisms. I'll see about getting
> the docs updated to save other people from going down that route.
>
> I've successfully implemented David's suggestion and have a DS component which
> creates configurations on activation, persists them when the configurations are
> modified & removes them when deleted. It all seems to work fine.
>
> The only minor issue is that factory configurations get a new PID each time they
> are created (as you can't AFAIK create a factory configuration with a specific
> PID). This has no impact.
>
> Thanks for the guidance.
>
> Paul
>
> On 22 March 2018 at 23:26, David Jencks <david.a.jencks@gmail.com
> <ma...@gmail.com>> wrote:
>
> A config admin implementation has to have all the preexisting persisted
> configurations available when the config admin service is registered. If I
> understand your description of what you implemented, this is not possible
> with your architecture. I’m suggesting your discard your current approach
> and write something that interacts with the config admin service as a
> management agent, i.e. it creates, modifies, and deletes configurations
> through the config admin api.
>
> David Jencks
>
> Sent from my iPhone
>
> On Mar 22, 2018, at 3:23 PM, Paul McCulloch <pkmcculloch@gmail.com
> <ma...@gmail.com>> wrote:
>
>> Thanks David. I'll try a Felix list, but if you wouldn't mind clarifying
>> some of what you said I'd be grateful.
>>
>> I don't directly create any Configuration instances. I just return an
>> Enumeration of Dictionary to Felix's config admin which creates
>> Configurations from this. I don't interact with config admin at all.
>>
>> Does that make any difference to your view on what I'm doing?
>>
>> Thanks for the idea regarding an alternative design.
>>
>> Paul
>>
>> http://felix.apache.org/apidocs/configadmin/1.6.0/org/apache/felix/cm/PersistenceManager.html#getDictionaries()
>> <http://felix.apache.org/apidocs/configadmin/1.6.0/org/apache/felix/cm/PersistenceManager.html#getDictionaries()>
>>
>> On 22 March 2018 at 21:40, David Jencks <david.a.jencks@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>> I suspect you are using the Felix config admin so your question more
>> properly belongs on the Felix lists.
>>
>> What you are doing can’t work as is. There are two times an unmodified
>> configuration is picked up by ds:
>> 1) when a configurable component is enabled.
>> 2) when the (Singleton) config admin service is detected by ds.
>>
>> Your plan to add an unmodified configuration to config admin after
>> both these events have occurred won’t result in ds picking up the
>> configuration. This is correct behavior and I hope you can’t convince
>> anyone to modify it.
>>
>> I suggest instead of breaking the working model of ds plus config
>> admin you make your auxiliary db persistence create new configurations
>> when it starts up and delete them when it shuts down. I think you can
>> then write it as a configuration management agent external to any
>> particular config admin implementation, and just not worry about the
>> fact that config admin is also storing the configurations locally.
>>
>> David Jencks
>>
>> Sent from my iPhone
>>
>> On Mar 22, 2018, at 1:30 PM, Paul McCulloch <pkmcculloch@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>>> Thanks for the reply.
>>>
>>> The component requiring the configuration that I'm persisting in the
>>> database is DS. The PersistenceManager is another DS component,
>>> injected with a JPA template (from Aries JPA). Currently
>>> my PersistenceManager only manages the configuration for this one
>>> other component - it delegates storing of all other configurations
>>> to the standard file based manager.
>>>
>>> The config admin service starts early - well before my persistence
>>> manager is started - but config admin does detect it and use it.
>>>
>>> From my debugging efforts it seems that configurations are used to
>>> satisfy a component at 2 points - when a component bundles is
>>> started, and when a configuration is created or updated. This works
>>> fine when the configuration is available before the other component
>>> (as is the usual case), or when the configuration is created via
>>> config admin.
>>>
>>> The configurations created from the data returned by the
>>> PersistenceManager don't seem to trigger the relevant operations. A
>>> PersistenceManager doesn't itself create configurations - it just
>>> gives the underlying Dictionary to the caller.
>>>
>>> As I said, updating the configurations after they have been created
>>> resolves the issue, as does mocking the PersistenceManager with
>>> something that can start earlier than my DS component requiring
>>> configuration. This leads me to believe that the essentials of my
>>> manager are sound.
>>>
>>>
>>> Paul
>>>
>>>
>>>
>>> On 22 March 2018 at 19:33, David Jencks <david.a.jencks@gmail.com
>>> <ma...@gmail.com>> wrote:
>>>
>>> I for one don’t understand which components of what kind (ds?
>>> Blueprint? Hard coded?) are having problems and how the
>>> components relate. For instance if the dB access for the
>>> configuration manager relies on a configuration retrieved from
>>> the dB, I don’t see how you will resolve the circularity. For
>>> configurations supplied to ds components I would not expect
>>> problems if the config admin service is registered after the
>>> persistence layer is fully functional and the config admin is
>>> fully aware of all the stored configurations. I don’t know if
>>> blueprint deals well with configurations showing up late, and
>>> hard coded stuff you would have to deal with yourself.
>>>
>>> David Jencks
>>>
>>> Sent from my iPhone
>>>
>>> On Mar 22, 2018, at 6:15 AM, Paul McCulloch
>>> <pkmcculloch@gmail.com <ma...@gmail.com>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm trying to implement a SQL backed Confg Admin persistence
>>>> mechanism to handle a subset of Karaf 4.1 configuration. My
>>>> implementation works for the most part - configurations are
>>>> displayed in the web console; new configurations are stored &
>>>> retrieved at startup.
>>>>
>>>> However, Services which require a configuration provided by
>>>> my PersistenceManager do not have their configuration recognised
>>>> at startup & do not get activated.
>>>>
>>>> I believe this is a timing issue. If I save the configuration
>>>> via the webconsole after startup then my Service starts. If I
>>>> change my PersistenceManager to not require the database service
>>>> (either a DataSource or a JPATemplate) & to deliver a hardcoded
>>>> configuration then my service starts.
>>>>
>>>> At the moment I have a nasty workaround of having a background
>>>> thread update all of my configurations once
>>>> the PersistenceManager has been called.
>>>>
>>>> Does this sound like a bug? Any hints on a better workaround?
>>>>
>>>> Thanks.
>>>>
>>>> Paul
>>>
>>>
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Custom PersistenceManager configurations not instantiating components
Posted by Paul McCulloch <pk...@gmail.com>.
I reviewed the Felix config admin implementation & it really isn't designed
to handle the late addition of new persistence mechanisms. I'll see about
getting the docs updated to save other people from going down that route.
I've successfully implemented David's suggestion and have a DS component
which creates configurations on activation, persists them when the
configurations are modified & removes them when deleted. It all seems to
work fine.
The only minor issue is that factory configurations get a new PID each time
they are created (as you can't AFAIK create a factory configuration with a
specific PID). This has no impact.
Thanks for the guidance.
Paul
On 22 March 2018 at 23:26, David Jencks <da...@gmail.com> wrote:
> A config admin implementation has to have all the preexisting persisted
> configurations available when the config admin service is registered. If I
> understand your description of what you implemented, this is not possible
> with your architecture. I’m suggesting your discard your current approach
> and write something that interacts with the config admin service as a
> management agent, i.e. it creates, modifies, and deletes configurations
> through the config admin api.
>
> David Jencks
>
> Sent from my iPhone
>
> On Mar 22, 2018, at 3:23 PM, Paul McCulloch <pk...@gmail.com> wrote:
>
> Thanks David. I'll try a Felix list, but if you wouldn't mind clarifying
> some of what you said I'd be grateful.
>
> I don't directly create any Configuration instances. I just return an
> Enumeration of Dictionary to Felix's config admin which creates
> Configurations from this. I don't interact with config admin at all.
>
> Does that make any difference to your view on what I'm doing?
>
> Thanks for the idea regarding an alternative design.
>
> Paul
>
> http://felix.apache.org/apidocs/configadmin/1.6.0/org/apache/felix/cm/
> PersistenceManager.html#getDictionaries()
>
> On 22 March 2018 at 21:40, David Jencks <da...@gmail.com> wrote:
>
>> I suspect you are using the Felix config admin so your question more
>> properly belongs on the Felix lists.
>>
>> What you are doing can’t work as is. There are two times an unmodified
>> configuration is picked up by ds:
>> 1) when a configurable component is enabled.
>> 2) when the (Singleton) config admin service is detected by ds.
>>
>> Your plan to add an unmodified configuration to config admin after both
>> these events have occurred won’t result in ds picking up the configuration.
>> This is correct behavior and I hope you can’t convince anyone to modify it.
>>
>> I suggest instead of breaking the working model of ds plus config admin
>> you make your auxiliary db persistence create new configurations when it
>> starts up and delete them when it shuts down. I think you can then write it
>> as a configuration management agent external to any particular config admin
>> implementation, and just not worry about the fact that config admin is also
>> storing the configurations locally.
>>
>> David Jencks
>>
>> Sent from my iPhone
>>
>> On Mar 22, 2018, at 1:30 PM, Paul McCulloch <pk...@gmail.com>
>> wrote:
>>
>> Thanks for the reply.
>>
>> The component requiring the configuration that I'm persisting in the
>> database is DS. The PersistenceManager is another DS component, injected
>> with a JPA template (from Aries JPA). Currently my PersistenceManager
>> only manages the configuration for this one other component - it delegates
>> storing of all other configurations to the standard file based manager.
>>
>> The config admin service starts early - well before my persistence
>> manager is started - but config admin does detect it and use it.
>>
>> From my debugging efforts it seems that configurations are used to
>> satisfy a component at 2 points - when a component bundles is started, and
>> when a configuration is created or updated. This works fine when the
>> configuration is available before the other component (as is the usual
>> case), or when the configuration is created via config admin.
>>
>> The configurations created from the data returned by the
>> PersistenceManager don't seem to trigger the relevant operations. A
>> PersistenceManager doesn't itself create configurations - it just gives
>> the underlying Dictionary to the caller.
>>
>> As I said, updating the configurations after they have been created
>> resolves the issue, as does mocking the PersistenceManager with
>> something that can start earlier than my DS component requiring
>> configuration. This leads me to believe that the essentials of my manager
>> are sound.
>>
>>
>> Paul
>>
>>
>>
>> On 22 March 2018 at 19:33, David Jencks <da...@gmail.com> wrote:
>>
>>> I for one don’t understand which components of what kind (ds? Blueprint?
>>> Hard coded?) are having problems and how the components relate. For
>>> instance if the dB access for the configuration manager relies on a
>>> configuration retrieved from the dB, I don’t see how you will resolve the
>>> circularity. For configurations supplied to ds components I would not
>>> expect problems if the config admin service is registered after the
>>> persistence layer is fully functional and the config admin is fully aware
>>> of all the stored configurations. I don’t know if blueprint deals well with
>>> configurations showing up late, and hard coded stuff you would have to deal
>>> with yourself.
>>>
>>> David Jencks
>>>
>>> Sent from my iPhone
>>>
>>> On Mar 22, 2018, at 6:15 AM, Paul McCulloch <pk...@gmail.com>
>>> wrote:
>>>
>>> Hi,
>>>
>>> I'm trying to implement a SQL backed Confg Admin persistence mechanism
>>> to handle a subset of Karaf 4.1 configuration. My implementation works for
>>> the most part - configurations are displayed in the web console; new
>>> configurations are stored & retrieved at startup.
>>>
>>> However, Services which require a configuration provided by
>>> my PersistenceManager do not have their configuration recognised at
>>> startup & do not get activated.
>>>
>>> I believe this is a timing issue. If I save the configuration via the
>>> webconsole after startup then my Service starts. If I change my
>>> PersistenceManager to not require the database service (either a
>>> DataSource or a JPATemplate) & to deliver a hardcoded configuration then my
>>> service starts.
>>>
>>> At the moment I have a nasty workaround of having a background thread
>>> update all of my configurations once the PersistenceManager has been
>>> called.
>>>
>>> Does this sound like a bug? Any hints on a better workaround?
>>>
>>> Thanks.
>>>
>>> Paul
>>>
>>>
>>
>
Re: Custom PersistenceManager configurations not instantiating components
Posted by David Jencks <da...@gmail.com>.
A config admin implementation has to have all the preexisting persisted configurations available when the config admin service is registered. If I understand your description of what you implemented, this is not possible with your architecture. I’m suggesting your discard your current approach and write something that interacts with the config admin service as a management agent, i.e. it creates, modifies, and deletes configurations through the config admin api.
David Jencks
Sent from my iPhone
> On Mar 22, 2018, at 3:23 PM, Paul McCulloch <pk...@gmail.com> wrote:
>
> Thanks David. I'll try a Felix list, but if you wouldn't mind clarifying some of what you said I'd be grateful.
>
> I don't directly create any Configuration instances. I just return an Enumeration of Dictionary to Felix's config admin which creates Configurations from this. I don't interact with config admin at all.
>
> Does that make any difference to your view on what I'm doing?
>
> Thanks for the idea regarding an alternative design.
>
> Paul
>
> http://felix.apache.org/apidocs/configadmin/1.6.0/org/apache/felix/cm/PersistenceManager.html#getDictionaries()
>
>> On 22 March 2018 at 21:40, David Jencks <da...@gmail.com> wrote:
>> I suspect you are using the Felix config admin so your question more properly belongs on the Felix lists.
>>
>> What you are doing can’t work as is. There are two times an unmodified configuration is picked up by ds:
>> 1) when a configurable component is enabled.
>> 2) when the (Singleton) config admin service is detected by ds.
>>
>> Your plan to add an unmodified configuration to config admin after both these events have occurred won’t result in ds picking up the configuration. This is correct behavior and I hope you can’t convince anyone to modify it.
>>
>> I suggest instead of breaking the working model of ds plus config admin you make your auxiliary db persistence create new configurations when it starts up and delete them when it shuts down. I think you can then write it as a configuration management agent external to any particular config admin implementation, and just not worry about the fact that config admin is also storing the configurations locally.
>>
>> David Jencks
>>
>> Sent from my iPhone
>>
>>> On Mar 22, 2018, at 1:30 PM, Paul McCulloch <pk...@gmail.com> wrote:
>>>
>>> Thanks for the reply.
>>>
>>> The component requiring the configuration that I'm persisting in the database is DS. The PersistenceManager is another DS component, injected with a JPA template (from Aries JPA). Currently my PersistenceManager only manages the configuration for this one other component - it delegates storing of all other configurations to the standard file based manager.
>>>
>>> The config admin service starts early - well before my persistence manager is started - but config admin does detect it and use it.
>>>
>>> From my debugging efforts it seems that configurations are used to satisfy a component at 2 points - when a component bundles is started, and when a configuration is created or updated. This works fine when the configuration is available before the other component (as is the usual case), or when the configuration is created via config admin.
>>>
>>> The configurations created from the data returned by the PersistenceManager don't seem to trigger the relevant operations. A PersistenceManager doesn't itself create configurations - it just gives the underlying Dictionary to the caller.
>>>
>>> As I said, updating the configurations after they have been created resolves the issue, as does mocking the PersistenceManager with something that can start earlier than my DS component requiring configuration. This leads me to believe that the essentials of my manager are sound.
>>>
>>>
>>> Paul
>>>
>>>
>>>
>>>> On 22 March 2018 at 19:33, David Jencks <da...@gmail.com> wrote:
>>>> I for one don’t understand which components of what kind (ds? Blueprint? Hard coded?) are having problems and how the components relate. For instance if the dB access for the configuration manager relies on a configuration retrieved from the dB, I don’t see how you will resolve the circularity. For configurations supplied to ds components I would not expect problems if the config admin service is registered after the persistence layer is fully functional and the config admin is fully aware of all the stored configurations. I don’t know if blueprint deals well with configurations showing up late, and hard coded stuff you would have to deal with yourself.
>>>>
>>>> David Jencks
>>>>
>>>> Sent from my iPhone
>>>>
>>>>> On Mar 22, 2018, at 6:15 AM, Paul McCulloch <pk...@gmail.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm trying to implement a SQL backed Confg Admin persistence mechanism to handle a subset of Karaf 4.1 configuration. My implementation works for the most part - configurations are displayed in the web console; new configurations are stored & retrieved at startup.
>>>>>
>>>>> However, Services which require a configuration provided by my PersistenceManager do not have their configuration recognised at startup & do not get activated.
>>>>>
>>>>> I believe this is a timing issue. If I save the configuration via the webconsole after startup then my Service starts. If I change my PersistenceManager to not require the database service (either a DataSource or a JPATemplate) & to deliver a hardcoded configuration then my service starts.
>>>>>
>>>>> At the moment I have a nasty workaround of having a background thread update all of my configurations once the PersistenceManager has been called.
>>>>>
>>>>> Does this sound like a bug? Any hints on a better workaround?
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Paul
>>>
>
Re: Custom PersistenceManager configurations not instantiating components
Posted by Paul McCulloch <pk...@gmail.com>.
Thanks David. I'll try a Felix list, but if you wouldn't mind clarifying
some of what you said I'd be grateful.
I don't directly create any Configuration instances. I just return an
Enumeration of Dictionary to Felix's config admin which creates
Configurations from this. I don't interact with config admin at all.
Does that make any difference to your view on what I'm doing?
Thanks for the idea regarding an alternative design.
Paul
http://felix.apache.org/apidocs/configadmin/1.6.0/org/apache/felix/cm/PersistenceManager.html#getDictionaries()
On 22 March 2018 at 21:40, David Jencks <da...@gmail.com> wrote:
> I suspect you are using the Felix config admin so your question more
> properly belongs on the Felix lists.
>
> What you are doing can’t work as is. There are two times an unmodified
> configuration is picked up by ds:
> 1) when a configurable component is enabled.
> 2) when the (Singleton) config admin service is detected by ds.
>
> Your plan to add an unmodified configuration to config admin after both
> these events have occurred won’t result in ds picking up the configuration.
> This is correct behavior and I hope you can’t convince anyone to modify it.
>
> I suggest instead of breaking the working model of ds plus config admin
> you make your auxiliary db persistence create new configurations when it
> starts up and delete them when it shuts down. I think you can then write it
> as a configuration management agent external to any particular config admin
> implementation, and just not worry about the fact that config admin is also
> storing the configurations locally.
>
> David Jencks
>
> Sent from my iPhone
>
> On Mar 22, 2018, at 1:30 PM, Paul McCulloch <pk...@gmail.com> wrote:
>
> Thanks for the reply.
>
> The component requiring the configuration that I'm persisting in the
> database is DS. The PersistenceManager is another DS component, injected
> with a JPA template (from Aries JPA). Currently my PersistenceManager
> only manages the configuration for this one other component - it delegates
> storing of all other configurations to the standard file based manager.
>
> The config admin service starts early - well before my persistence manager
> is started - but config admin does detect it and use it.
>
> From my debugging efforts it seems that configurations are used to satisfy
> a component at 2 points - when a component bundles is started, and when a
> configuration is created or updated. This works fine when the configuration
> is available before the other component (as is the usual case), or when the
> configuration is created via config admin.
>
> The configurations created from the data returned by the
> PersistenceManager don't seem to trigger the relevant operations. A
> PersistenceManager doesn't itself create configurations - it just gives
> the underlying Dictionary to the caller.
>
> As I said, updating the configurations after they have been created
> resolves the issue, as does mocking the PersistenceManager with something
> that can start earlier than my DS component requiring configuration. This
> leads me to believe that the essentials of my manager are sound.
>
>
> Paul
>
>
>
> On 22 March 2018 at 19:33, David Jencks <da...@gmail.com> wrote:
>
>> I for one don’t understand which components of what kind (ds? Blueprint?
>> Hard coded?) are having problems and how the components relate. For
>> instance if the dB access for the configuration manager relies on a
>> configuration retrieved from the dB, I don’t see how you will resolve the
>> circularity. For configurations supplied to ds components I would not
>> expect problems if the config admin service is registered after the
>> persistence layer is fully functional and the config admin is fully aware
>> of all the stored configurations. I don’t know if blueprint deals well with
>> configurations showing up late, and hard coded stuff you would have to deal
>> with yourself.
>>
>> David Jencks
>>
>> Sent from my iPhone
>>
>> On Mar 22, 2018, at 6:15 AM, Paul McCulloch <pk...@gmail.com>
>> wrote:
>>
>> Hi,
>>
>> I'm trying to implement a SQL backed Confg Admin persistence mechanism to
>> handle a subset of Karaf 4.1 configuration. My implementation works for the
>> most part - configurations are displayed in the web console; new
>> configurations are stored & retrieved at startup.
>>
>> However, Services which require a configuration provided by
>> my PersistenceManager do not have their configuration recognised at
>> startup & do not get activated.
>>
>> I believe this is a timing issue. If I save the configuration via the
>> webconsole after startup then my Service starts. If I change my
>> PersistenceManager to not require the database service (either a
>> DataSource or a JPATemplate) & to deliver a hardcoded configuration then my
>> service starts.
>>
>> At the moment I have a nasty workaround of having a background thread
>> update all of my configurations once the PersistenceManager has been
>> called.
>>
>> Does this sound like a bug? Any hints on a better workaround?
>>
>> Thanks.
>>
>> Paul
>>
>>
>
Re: Custom PersistenceManager configurations not instantiating components
Posted by David Jencks <da...@gmail.com>.
I suspect you are using the Felix config admin so your question more properly belongs on the Felix lists.
What you are doing can’t work as is. There are two times an unmodified configuration is picked up by ds:
1) when a configurable component is enabled.
2) when the (Singleton) config admin service is detected by ds.
Your plan to add an unmodified configuration to config admin after both these events have occurred won’t result in ds picking up the configuration. This is correct behavior and I hope you can’t convince anyone to modify it.
I suggest instead of breaking the working model of ds plus config admin you make your auxiliary db persistence create new configurations when it starts up and delete them when it shuts down. I think you can then write it as a configuration management agent external to any particular config admin implementation, and just not worry about the fact that config admin is also storing the configurations locally.
David Jencks
Sent from my iPhone
> On Mar 22, 2018, at 1:30 PM, Paul McCulloch <pk...@gmail.com> wrote:
>
> Thanks for the reply.
>
> The component requiring the configuration that I'm persisting in the database is DS. The PersistenceManager is another DS component, injected with a JPA template (from Aries JPA). Currently my PersistenceManager only manages the configuration for this one other component - it delegates storing of all other configurations to the standard file based manager.
>
> The config admin service starts early - well before my persistence manager is started - but config admin does detect it and use it.
>
> From my debugging efforts it seems that configurations are used to satisfy a component at 2 points - when a component bundles is started, and when a configuration is created or updated. This works fine when the configuration is available before the other component (as is the usual case), or when the configuration is created via config admin.
>
> The configurations created from the data returned by the PersistenceManager don't seem to trigger the relevant operations. A PersistenceManager doesn't itself create configurations - it just gives the underlying Dictionary to the caller.
>
> As I said, updating the configurations after they have been created resolves the issue, as does mocking the PersistenceManager with something that can start earlier than my DS component requiring configuration. This leads me to believe that the essentials of my manager are sound.
>
>
> Paul
>
>
>
>> On 22 March 2018 at 19:33, David Jencks <da...@gmail.com> wrote:
>> I for one don’t understand which components of what kind (ds? Blueprint? Hard coded?) are having problems and how the components relate. For instance if the dB access for the configuration manager relies on a configuration retrieved from the dB, I don’t see how you will resolve the circularity. For configurations supplied to ds components I would not expect problems if the config admin service is registered after the persistence layer is fully functional and the config admin is fully aware of all the stored configurations. I don’t know if blueprint deals well with configurations showing up late, and hard coded stuff you would have to deal with yourself.
>>
>> David Jencks
>>
>> Sent from my iPhone
>>
>>> On Mar 22, 2018, at 6:15 AM, Paul McCulloch <pk...@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> I'm trying to implement a SQL backed Confg Admin persistence mechanism to handle a subset of Karaf 4.1 configuration. My implementation works for the most part - configurations are displayed in the web console; new configurations are stored & retrieved at startup.
>>>
>>> However, Services which require a configuration provided by my PersistenceManager do not have their configuration recognised at startup & do not get activated.
>>>
>>> I believe this is a timing issue. If I save the configuration via the webconsole after startup then my Service starts. If I change my PersistenceManager to not require the database service (either a DataSource or a JPATemplate) & to deliver a hardcoded configuration then my service starts.
>>>
>>> At the moment I have a nasty workaround of having a background thread update all of my configurations once the PersistenceManager has been called.
>>>
>>> Does this sound like a bug? Any hints on a better workaround?
>>>
>>> Thanks.
>>>
>>> Paul
>
Re: Custom PersistenceManager configurations not instantiating components
Posted by Paul McCulloch <pk...@gmail.com>.
Thanks for the reply.
The component requiring the configuration that I'm persisting in the
database is DS. The PersistenceManager is another DS component, injected
with a JPA template (from Aries JPA). Currently my PersistenceManager only
manages the configuration for this one other component - it delegates
storing of all other configurations to the standard file based manager.
The config admin service starts early - well before my persistence manager
is started - but config admin does detect it and use it.
From my debugging efforts it seems that configurations are used to satisfy
a component at 2 points - when a component bundles is started, and when a
configuration is created or updated. This works fine when the configuration
is available before the other component (as is the usual case), or when the
configuration is created via config admin.
The configurations created from the data returned by the PersistenceManager
don't seem to trigger the relevant operations. A PersistenceManager doesn't
itself create configurations - it just gives the underlying Dictionary to
the caller.
As I said, updating the configurations after they have been created
resolves the issue, as does mocking the PersistenceManager with something
that can start earlier than my DS component requiring configuration. This
leads me to believe that the essentials of my manager are sound.
Paul
On 22 March 2018 at 19:33, David Jencks <da...@gmail.com> wrote:
> I for one don’t understand which components of what kind (ds? Blueprint?
> Hard coded?) are having problems and how the components relate. For
> instance if the dB access for the configuration manager relies on a
> configuration retrieved from the dB, I don’t see how you will resolve the
> circularity. For configurations supplied to ds components I would not
> expect problems if the config admin service is registered after the
> persistence layer is fully functional and the config admin is fully aware
> of all the stored configurations. I don’t know if blueprint deals well with
> configurations showing up late, and hard coded stuff you would have to deal
> with yourself.
>
> David Jencks
>
> Sent from my iPhone
>
> On Mar 22, 2018, at 6:15 AM, Paul McCulloch <pk...@gmail.com> wrote:
>
> Hi,
>
> I'm trying to implement a SQL backed Confg Admin persistence mechanism to
> handle a subset of Karaf 4.1 configuration. My implementation works for the
> most part - configurations are displayed in the web console; new
> configurations are stored & retrieved at startup.
>
> However, Services which require a configuration provided by
> my PersistenceManager do not have their configuration recognised at
> startup & do not get activated.
>
> I believe this is a timing issue. If I save the configuration via the
> webconsole after startup then my Service starts. If I change my
> PersistenceManager to not require the database service (either a
> DataSource or a JPATemplate) & to deliver a hardcoded configuration then my
> service starts.
>
> At the moment I have a nasty workaround of having a background thread
> update all of my configurations once the PersistenceManager has been
> called.
>
> Does this sound like a bug? Any hints on a better workaround?
>
> Thanks.
>
> Paul
>
>
Re: Custom PersistenceManager configurations not instantiating components
Posted by David Jencks <da...@gmail.com>.
I for one don’t understand which components of what kind (ds? Blueprint? Hard coded?) are having problems and how the components relate. For instance if the dB access for the configuration manager relies on a configuration retrieved from the dB, I don’t see how you will resolve the circularity. For configurations supplied to ds components I would not expect problems if the config admin service is registered after the persistence layer is fully functional and the config admin is fully aware of all the stored configurations. I don’t know if blueprint deals well with configurations showing up late, and hard coded stuff you would have to deal with yourself.
David Jencks
Sent from my iPhone
> On Mar 22, 2018, at 6:15 AM, Paul McCulloch <pk...@gmail.com> wrote:
>
> Hi,
>
> I'm trying to implement a SQL backed Confg Admin persistence mechanism to handle a subset of Karaf 4.1 configuration. My implementation works for the most part - configurations are displayed in the web console; new configurations are stored & retrieved at startup.
>
> However, Services which require a configuration provided by my PersistenceManager do not have their configuration recognised at startup & do not get activated.
>
> I believe this is a timing issue. If I save the configuration via the webconsole after startup then my Service starts. If I change my PersistenceManager to not require the database service (either a DataSource or a JPATemplate) & to deliver a hardcoded configuration then my service starts.
>
> At the moment I have a nasty workaround of having a background thread update all of my configurations once the PersistenceManager has been called.
>
> Does this sound like a bug? Any hints on a better workaround?
>
> Thanks.
>
> Paul