Work-around for Cellar not supporting blueprint managed-service factory replication

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Work-around for Cellar not supporting blueprint managed-service factory replication

steve.lombardi
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?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Work-around for Cellar not supporting blueprint managed-service factory replication

jbonofre
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é
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Work-around for Cellar not supporting blueprint managed-service factory replication

steve.lombardi
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?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Work-around for Cellar not supporting blueprint managed-service factory replication

jbonofre
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é
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Loading...