You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by "steve.lombardi" <st...@connexta.com> on 2017/07/11 00:28:49 UTC
Work-around for Cellar not supporting blueprint managed-service
factory replication
To the Karaf team:
1. We understand that managed-service factories *are not* recommended for
use by Jean
(http://karaf.922171.n3.nabble.com/Sharing-configuration-with-Cellar-td4037365.html).
2. That being said, we understand Cellar will replicate the configurations
but will not create the factory itself. We tried the reproduction steps
(http://karaf.922171.n3.nabble.com/Problem-with-Cellar-and-ManagedServiceFactories-td4037937.html)
and they *did not* work with Karaf 4.1.1 and Cellar 4.1.0 using default
property excludes (including factory.pid).
Do our blueprint bundles need to do something special? Do they need to
pre-create the factories in the container so Cellar config sync works
correctly? I don't think so; it won't work anyway.
Cellar does not call configurationAdmin.createFactoryConfiguration(), it
instead calls configurationAdmin.getConfiguration() with a PID that
represents a managed-service factory instance (e.g. factoryPID-UUID).
The end result is that the bean registered with blueprint is never
instantiated, even if other beans were instantiated belonging to that
factory. The steps cited here
(http://karaf.922171.n3.nabble.com/Problem-with-Cellar-and-ManagedServiceFactories-td4037937.html)
would never work with a blueprint bundle that uses
<cm:managed-service-factory> and <cm:managed-component>.
Do we need to provide our own implementation of ManagedServiceFactory
(https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ManagedServiceFactory.html)
to offset how blueprint does it
(https://github.com/apache/aries/blob/trunk/blueprint/blueprint-cm/src/main/java/org/apache/aries/blueprint/compendium/cm/BaseManagedServiceFactory.java#L38)
if we want Cellar to work?
--
View this message in context: http://karaf.922171.n3.nabble.com/Work-around-for-Cellar-not-supporting-blueprint-managed-service-factory-replication-tp4050981.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: Work-around for Cellar not supporting blueprint managed-service
factory replication
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Steve,
see my comments inline:
On 07/11/2017 08:54 PM, steve.lombardi wrote:
> Jean:
>
> That would be spectacular. Many thanks. Please let us know if we can help.
> We have our own release in August and may have some time shortly after to
> contribute, depending on the Cellar 4.1.2 release timeline.
It could work for end of August (I'm in vacation mid-August).
>
> There are other parts to this issue as well:
>
> (1) Karaf 4.1.1 supports `.cfg` and `.config` files but Cellar 4.1.0 only
> supports `.cfg` which can lead to problems serializing configs with arrays.
Cellar only deals with ConfigAdmin for now, not directly the files in etc
folder. Cellar "traps" the ConfigAdmin events and spread them on the cluster.
>
> (2) Cellar does not persist the replicated managed-service factory
> configurations to disk, which means the etc directories on multiple nodes
> can fall out of sync.
For the same reason as previous point.
>
> For the Cellar Config fix in 4.1.2, do you plan to continue using the PID to
> correlate configurations across the cluster? If so, will you use the
> existing configAdmin.createFactoryConfiguration() or a new function that
> forces the use of the same PID
>
> Alternatively, would you use a separate property similar to
> felix.fileinstall.filename to correlate configurations?
In the past, I introduced a special property (to avoid infinite loop during
sync). It could be a new way of dealing with cfg file. Let me think about that.
Regards
JB
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Work-around-for-Cellar-not-supporting-blueprint-managed-service-factory-replication-tp4050981p4050987.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Work-around for Cellar not supporting blueprint managed-service
factory replication
Posted by "steve.lombardi" <st...@connexta.com>.
Jean:
That would be spectacular. Many thanks. Please let us know if we can help.
We have our own release in August and may have some time shortly after to
contribute, depending on the Cellar 4.1.2 release timeline.
There are other parts to this issue as well:
(1) Karaf 4.1.1 supports `.cfg` and `.config` files but Cellar 4.1.0 only
supports `.cfg` which can lead to problems serializing configs with arrays.
(2) Cellar does not persist the replicated managed-service factory
configurations to disk, which means the etc directories on multiple nodes
can fall out of sync.
For the Cellar Config fix in 4.1.2, do you plan to continue using the PID to
correlate configurations across the cluster? If so, will you use the
existing configAdmin.createFactoryConfiguration() or a new function that
forces the use of the same PID?
Alternatively, would you use a separate property similar to
felix.fileinstall.filename to correlate configurations?
--
View this message in context: http://karaf.922171.n3.nabble.com/Work-around-for-Cellar-not-supporting-blueprint-managed-service-factory-replication-tp4050981p4050987.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: Work-around for Cellar not supporting blueprint managed-service
factory replication
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Steve,
I created a Jira about that while ago.
The idea in Cellar Config is to detect factory PID and then replicate the config
correctly.
It won't be included in Cellar 4.1.1, but I can include that for 4.1.2 release.
Regards
JB
On 07/11/2017 02:28 AM, steve.lombardi wrote:
> To the Karaf team:
>
> 1. We understand that managed-service factories *are not* recommended for
> use by Jean
> (http://karaf.922171.n3.nabble.com/Sharing-configuration-with-Cellar-td4037365.html).
>
> 2. That being said, we understand Cellar will replicate the configurations
> but will not create the factory itself. We tried the reproduction steps
> (http://karaf.922171.n3.nabble.com/Problem-with-Cellar-and-ManagedServiceFactories-td4037937.html)
> and they *did not* work with Karaf 4.1.1 and Cellar 4.1.0 using default
> property excludes (including factory.pid).
>
> Do our blueprint bundles need to do something special? Do they need to
> pre-create the factories in the container so Cellar config sync works
> correctly? I don't think so; it won't work anyway.
>
> Cellar does not call configurationAdmin.createFactoryConfiguration(), it
> instead calls configurationAdmin.getConfiguration() with a PID that
> represents a managed-service factory instance (e.g. factoryPID-UUID).
>
> The end result is that the bean registered with blueprint is never
> instantiated, even if other beans were instantiated belonging to that
> factory. The steps cited here
> (http://karaf.922171.n3.nabble.com/Problem-with-Cellar-and-ManagedServiceFactories-td4037937.html)
> would never work with a blueprint bundle that uses
> <cm:managed-service-factory> and <cm:managed-component>.
>
> Do we need to provide our own implementation of ManagedServiceFactory
> (https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ManagedServiceFactory.html)
> to offset how blueprint does it
> (https://github.com/apache/aries/blob/trunk/blueprint/blueprint-cm/src/main/java/org/apache/aries/blueprint/compendium/cm/BaseManagedServiceFactory.java#L38)
> if we want Cellar to work?
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Work-around-for-Cellar-not-supporting-blueprint-managed-service-factory-replication-tp4050981.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com