Hi, Using the dependencymanager, when registering a component with a factory and a (required) ConfigurationDependency. When the configuration becomes available the component instance is retrieved from the factory and then onUpdate is called on the component instance. Seems reasonable, but what if my factory requires the configuration to be able to properly instantiate the component instance? Is that a valid use case?
My motivation for trying the factory approach was to weed out OSGi service lifecycle specifics from the actual service implementation reducing it to a business logic only POJO. So maybe a more general question is how this could be done? Right now I can create a separate MyBusinessServiceImpl that implements MyBusiness, handles all lifecycle stuff and delegates all MyBusiness methods to the underlying MyBusinessImpl object? But that seems kind of cumbersome, especially when the MyBusiness interface contains a lot of methods (and I do not want to use reflection). Another way would be to extend a base class, but then again I'm coupling my business logic to the OSGi/DependecyManager specifics. So I was thinking. What if Dependencymanager would allow you to specify a "ComponentManager" class/object that would be responsible for handling all lifecycle callbacks, configuration callbacks and maybe be the factory? Actually I think this is stuff I would normally put in the activator, but when using Dependencymanager you lose some of this fexibility? WDYT? Regards, Bram --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
