On 22 Nov 2010, at 10:52 , Bram de Kruijff wrote: > Hi Marcel, > > On Fri, Nov 19, 2010 at 2:05 PM, Marcel Offermans > <[email protected]> wrote: >> Hello Bram, >> >> On 19 Nov 2010, at 13:45 , Bram de Kruijff wrote: >> >>> 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? >> >> It is already possible to use a separate instance to handle all callbacks >> for a component. You can specify it when defining your callback methods, so: >> >> manager.add(createComponent() >> .setImplementation(MyBusinessImpl.class) >> .setCallbacks(new CallbackHandler(), "init", "start", /* etc... */ >> >> with: >> >> class CallbackHandler { >> public void init(Component c) { >> // your code goes here >> } >> public void start(Component c) { >> // and here, etc. >> } >> >> Through the Component interface you gain access to the actual instance and >> many other relevant things, and you can even use this mechanism to add more >> dependencies, or further configure the implementation based on the >> configuration. So essentially, you can make the callback handler into a >> factory. > > Thanks, I overlooked this signature. However, it seems only to solve > my case partially as I do not get the updated on the callback handler. > A quick look at the code seems to indicate that the > ConfigurationDependency does not consider the callbackhandler(?) I > guess if this where the case indeed this mechanism would allow me to > fully seperate business and service logic and create the factory I am > looking for.
The callback handler you set is for the (init, start, stop and destroy) life cycle methods of the component. Dependencies have their own callbacks and can also get their own callback handlers. For example, take a look at a service dependency, it also has a setCallbacks() method and does support a callback handler. Currently, configuration dependencies do not support such a method, but I think it is worth considering adding this as an extension. The question I have for you is, is the validation of a configuration part of your business logic, or considered "OSGi plumbing" (what you call "service logic")? Greetings, Marcel --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
