Dynamic nested properties

[barrel]

Yep, basically it means that I have to 'implement' the lifecycle management myself.
First instantiate (partially programmatic) all beans since I definitely do not want a depends-on a dynamic list and afterwards initialize....

Thanks for the help,
Barry

[irbouho]

If all the devices implement an IDevice interface, you can make DeviceManager look for devices using factory.getBeansOfType(IDevice.class). DeviceManager needs, of course, to implement BeanFactoryAware. This Implies that all devices will be manager by the same manager.
HTH

Isn't this simpler to do?

[barrel]

If all the devices implement an IDevice interface, you can make DeviceManager look for devices using factory.getBeansOfType(IDevice.class). DeviceManager needs, of course, to implement BeanFactoryAware. This Implies that all devices will be manager by the same manager.
HTH

Isn't this simpler to do?

Well.... yes and no. Simpler because it does what I want to do, but not simpler since I would make my code dependant of Spring.

We are currently changing from Avalon to Spring, but I want to be able to switch just as quickly to Pico (for instance) if Spring doesn't do what I want to do.....

On the other hand... it is worth giving a try :wink:

[Andreas Senft]

One thing I just thought of:

If you can live with having your device beans in another configuration file (or several other configuration file) than the device-manager bean you could do the following:

Initialize your device-manager with a BeanPostProcessor which looks up the other configuration files and loads the contained device-beans. For this you could use the approach I mentioned some postings above. This way you do not have to take care about the order in which beans will be initialized within one context file. The lookup path/ file pattern might be configured with properties of your BeanPostProcessor.

Regards,
Andreas