He Marcel,
On Mon, Jan 3, 2011 at 11:09 AM, Marcel Offermans
<[email protected]> wrote:
> On Jan 3, 2011, at 10:57 , Bram de Kruijff wrote:
>
>> question/observation about the dependencymanager callbacks contract. I
>> noticed that init() was being invoked more then once over the lifespan
>> of my service instance because 1) I constructed it with an instance
>> (insted of class/factory)
>
> Indeed, if you construct the component and supply an already created
> instance, the dependency manager will use that instance every time instead of
> constructing a new one itself every time the components needs to be created.
> So if you create an instance yourself, make sure it can handle multiple life
> cycles.
>
>> and 2) I was adding dependencies in init,
>> leading to duplicates, leading to multiple service dependecy
>> callbacks.
>
> If you add dependencies in init, you run the risk of your component getting
> deactivated immediately. Since that can lead to complicated logic in your
> component, you should use setInstanceBound(true) for such components, which
> ensures that if an instance was already created, it will not go away again,
> not even when a required dependency is not available. The instance will just
> sit there and wait for that dependency to show up again.
Sorry but I do not get the setInstanceBound(true) thing. It seems you
can set it on a Dependecy but what does it mean? Does "it will not go
away again" refer to the service instance or the service registration.
In case of the former, will it solve my problem as init wont be called
again? in case of the latter, it is like a require once and afterwards
it might be a NullObject?
>>
>> // Eg. This will result in multiple service dependencies upon
>> logservice (un)availibility as we will go throught init/destroy each
>> cycle
>> public synchronized void init() {
>> ServiceDependency logServiceDependency =
>> m_dependencyManager.createServiceDependency();
>> logServiceDependency.setService(LogService.class);
>> logServiceDependency.setRequired(true);
>> m_component.add(logServiceDependency);
>> }
>
> The other solution would be to immediately add such a dependency instead of
> dynamically adding it after the component is being activated.
Yeah I know, but I just moved all "internal concerns" to init so this
is how I got there :) For now, using a factory also does the trick.
> By the way, why do you make LogService a required dependency? In general I
> think that's a bad idea, since it will bring down your whole application if
> logging for some reason is not available (if you update the log bundle).
Probably not the best example indeed :)
>> My (naive) assumption was that init() would be called once and only
>> once an a service instance, but as it seems init/destroy is called
>> each time a required service becomes (unavailable).
>
> [...]
>
>> Question is why and what is the contract? Obvisouly, the fact that
>> this results in different behaviour depending on how one instantiates
>> the Component is rather confusing :S
>
> See above, it will only if *you* supply an already created instance. In that
> case, I cannot assume I can create a new instance so I have to reuse the
> existing one. If you don't want that, either supply the class or a custom
> factory so I can invoke it to create an instance.
Still confused... why go through init/destroy every time? What is the
logical distinction between init/start and stop/destroy if they all
get called every time. Or is there a case where you only hit
stop/start? As the doc says you only go through start once all
required deps are present, I was expecting the reverse when one
disappears. Therefore was expecting just stop/start (aka bind/unbind)
upon required service (un)availibility.
Trying to grasp the concepts here :)
Regards,
Bram
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
