Hello Bram,
On 19 Nov 2010, at 13:45 , Bram de Kruijff wrote:
> 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?
It is a valid use case, but not supported by the factories in the dependency
manager as they do not have knowledge of the dependencies of a component. The
process currently is to first use the factory to create an instance (or a
composition of instances) and then inject dependencies.
In theory I could try to be smart when looking for a factory create method and
try to see if any arguments of that method map to dependencies of the
component, but I can see that quickly becoming a tricky business (what if
multiple create methods exist, what if multiple dependencies of the same type
exist, etc.).
> 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?
That's a good question!
> 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.
There are other options...
> 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.
Note: if you want to do this in the activator, just use:
manager.add(createComponent()
.setImplementation(MyBusinessImpl.class)
.setCallbacks(this, "init", "start", /* etc... */
from within your activator, and the callbacks will be invoked on it.
Greetings, Marcel
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
