[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] DS optional cardinality question
- From: BJ Hargrave <hargrave@xxxxxxxxxx>
- Date: Thu, 2 Mar 2006 11:54:03 -0500
- Delivered-to: firstname.lastname@example.org
equinox-dev-bounces@xxxxxxxxxxx wrote on 2006-03-02 11:27:42 AM:
> BJ, Roy,
> Thanks for the responses. But I am still concerned:
> Based on the meta-data, the component "Manager" could come up and
> operate when a optional service that it has a reference to is not
> available. correct ?
> Does this mean, bootstrapping "Manager" should
> not automatically bootstrap "Listener1" and "Listener2" ? This is
> what I see happening right now.
Manager is immediate, so SCR must activate it if it can. Since Manager
reference Listeners and 2 are available, Manager is supplied with the
available Listeners. Since Manager uses event strategy (DI) and (I assume)
does not request ServiceReferences, SCR must supply real objects for the
Listeners, thus they are activated.
The DS design does allow an SCR implementation to use proxy objects. So
SCR could create proxies for the Listeners which could then delay
instantiating the Listener componentes until a method call is made.
However, the SCR impl in Equinox does not currently do this.
> The model I have in mind is that the
> services "Listener1" and "Listener2" can be activated due to some
> other dependencies (unrelated to Manager), and when they do, they
> get injected into Manager. In my view, activating "Manager" should
> not activate all listeners. Can you explain the rationale for this
If the Listeners did have some other dependency that could not be
satisfied then they would not be able to be activated and supplied to
Manager until their dependencies were met. Since they do not have any such
dependencies, they can be activated right away.
> I do not want to use lookup strategy in my component because I want
> to avoid framework bleed into my component code. This is not a good
> choice for me. So, alternatively, is there a way to implement the
> collaborator pattern I described without using lookup strategy ?
The only thing I can think of if to have SCR add proxy support. There
needs to be some trigger to instantiate the Listener components. If you
don't use lookup, then a method call across a proxy is the other choice.
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
Office: +1 407 849 9117 Mobile: +1 386 848 3788