Hi Christian,

Answers in line:

On 18 Jul 2014, at 14:21, Christian Schneider <[email protected]> wrote:

> I have the following case in ops4j pax-jdbc-config
> https://github.com/ops4j/org.ops4j.pax.jdbc/tree/master/pax-jdbc-config
> 
> I have a ManagesServiceFactory that watches for configs (representing desired 
> datasources) being created and destroyed.
> For each config I select a DataSourceFactory service by properties specified 
> in the config. I then create DataSource and publish it as a service.
> When the config disappears I have to remove the service again.
> 
> The difficult thing here is that at the moment when the "updated" for the 
> config comes in there may not yet be a suitable DataSourceFactory service. In 
> my first prototype I then just do not create the DataSource.
> The problem with this is of course that at startup it is very probable that 
> the configs come in before the DataSourceFactories are up. So my current 
> approach leads to the problem that the DataSources are not created at all in 
> some cases.

Assuming that you’re listening for the DataSourceFactory services being 
registered (which you should be) then you can dequeue the pending configs as 
soon as the relevant DSD becomes available. You should also be unregistering 
the DataSource if the DataSourceFactory that created it gets unregistered.

> 
> So are there any best practices or patterns how to handle this?

Declarative Services will help a lot with lifecycle tracking, and with 
receiving configuration. Bnd’s Configurable makes configuration dictionaries 
easier to use in a type-safe way.

> I think it is a bit similar to blueprint that needs to wait for namespace 
> handlers. I am not sure though if the timeout approach blueprint uses is a 
> good way to approach this. On the other hand you have to report back to the 
> user that his config might be wrong at some point.

I would suggest putting a timestamp on the configuration as it is queued, and 
having a Timer that periodically checks the state of the world. If a 
configuration has been queued for more than X (probably another config 
parameter) then you can log out that there might be a problem.

> 
> Christian
> 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Open Source Architect
> http://www.talend.com
> 
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev

_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to