Configurations best practice?

[Mark Derricutt <ma...@talios.com>]

Hey all,

I was wondering if anyone could point in the right direction for a 'best
practice' in using the configuration admin service.

In my current setup I have database credentials nastily defined as system
properties and a DatabaseProvider interface/implementation that returns
them.  DatabaseProvider instances are used by two other components: admin
and statistics who live in separate bundles.

Now that I'm wanting to move to using the configuration admin service, I'm
finding difficulty with the fact that no configuration can exist (at least
on services that want immediate action taken).  Currently, I have an
AdminService and a StatisticsService depending on the DatabaseProvider
service, which is fine when a configuration exists, but in the case where no
configuration currently exists, or the configuration is changed/removed
things blow up.

What I need is a way to listen to the fact that the DatabaseProvider has
been updated with new configuration details, and react accordingly on the
dependant service.

Whats the best way of handling this?  Would I be better off having say a
DatabaseCredentials service, which registers a DatabaseProvider service in
its ManagedService#updated() method (and deregisters accordingly) and have
AdminService depend on that (allowing me to react on an
(set|unset)DatabaseProvider() method) or some other way?

Thanks,
Mark



-- 
"It is easier to optimize correct code than to correct optimized code." --
Bill Harlan

Re: Configurations best practice?

[Mark Derricutt <ma...@talios.com>]

Well I now have this working seemingly quite well:

* DatabaseProviderAdmin component with associated configuration, registers a
DatabaseProvider service when update() is called with a valid configuration,
and unregisters when null is passed in.
* Entity Manager component has a reference to a DatabaseProvider service
with policy="dynamic" which enables its hibernate discovery extender/session
factory service registration when a DatabaseProvider is set, disabling it
and unregistering the sessionFactory when the component is deactivated.
* Other services/bundles use the SessionFactory as normal.


Things to note:

Spring-DM's @ServiceReference annotation is darn handy for easily looking up
a service and injecting it into your beans, but doesn't provide a set/unset
notification process  (spring-dm's <osgi:reference> element however does).
The use of @ServiceReference sent my code, and my thought process down a
tunnel of 'the service is always there'.

Once I backtracked and started just using SCR and got my mindset refocused
things started to fall rather simply into shape.


On Mon, Aug 4, 2008 at 5:06 PM, Mark Derricutt <ma...@talios.com> wrote:

> In my current setup I have database credentials nastily defined as system
> properties and a DatabaseProvider interface/implementation that returns
> them.  DatabaseProvider instances are used by two other components: admin
> and statistics who live in separate bundles.
>


-- 
"It is easier to optimize correct code than to correct optimized code." --
Bill Harlan