Configuration of singletons

[fci]

Hello,

We are using spring dm with very good results. It is a great product.
However, we notice that the approach of configuring a singleton bean is not what we would like to have. Maybe there is a better way to configure...

The fact is that when we want to configure a bean using the config admin for a factory, everything goes fine, and the order is:

1- Bundle containing bean is started
2- Configuration Arrives with the pid x
3- Bean is initialized (initialization method is called) and ready to go

But when we work with a singleton we have:

1- Bundle containing bean is started
2- Application context is configured and so we have bean initialized
3- Configuration arrives with the pid x

So, we could have the bean initialization method without the configuration injected.

Is there a way to get the bundle initialized only after the configuration arrives? I mean, without overwriting the update method manually.
Because I don't see the point of having the bundle initialized before having it configured.

Thanks a lot in advance.
Fernando

[fci]

Ok I will use factories...

[Costin Leau]

Postponing context creation based on arbitrary generic events is hard to achieve because the problem is hard to describe.
My advice is to use factories which can control the objects you want to serve based on the configuration rules you need.
Note that in general, when using asynchronous mechanism your system will need to cope with the fact that some pieces of information are just not available - blocking a system in order to receive an event is literally serializing an unserialized system or in other words synchronizing an asynchronous process.

[fci]

Yes, I understand your point. But for me is like where you need to resolve the dependencies of a bundle. It is true that the bundle cannot work without having its dependencies resolved and thus, is blocking for the bundle initialization.
The same thing (but at different level) is for me the configuration of the bean. If one bean in the bundle is a singleton, and that bean needs a configuration. I don't see the point to having the bean initialized without the configuration.

Talking with xml, you configure a singleton with managed props like this:

<bean id="managedComponent" class="MessageTank">
     <osgix:managed-properties persistent-id="com.xyz.messageservice"/>
</bean>

My complain is that the bean is created without configuration.

What would be great is to have something (similar to factory) like:

<osgix:managed-propeties pid="com.xyz.messageservice" auto-export="interface"> ·
  <bean class="com.xyz.MessageTank"/> ¸
</osgix:managed-properties>

Which would mean: Instantiate a singleton "com.xyz.MessageTank" when the configuration with pid com.xyz.messageservice arrives. If the configuration does not arrives, the service will not be available.

This way we know the singleton is there, and available as a service, only when its configuration arrives.

[Costin Leau]

My understanding of the second configuration, just by looking at it, is that a (potentially managed) Properties object is being returned which is somehow related/uses the nested bean.

Feel free to raise an issue so the request doesn't get lost. Since configuration admin updates are sent asynchronous, there are literally no guarantees when the update will arrive or whether it contains any relevant information.
Relying on a set of defaults sounds or providing a 'startup barrier' which waits for the proper configuration to occur, might also do the trick.