Just to follow up on this, the additional injector created in the activator on line 41:
doesn't define a binding from DefaultBeanLocator.class to the shared locator, so it creates its own instance causing a split-brain situation. Also since the extender bundle will automatically create an injector with scanning enabled once the bundle reaches the 'started' state you're effectively duplicating work and bindings here.
I think what you're looking for is something like the old Sisu context utility class, which provided a quick way to get the active BeanLocator from Eclipse plug-ins:
This feature was temporarily moved out so it could be reworked (along with scanning of bundles in 'starting' state, which is required if you want to use injection in the actual start method).
Now that the extender has been separated from the core bundle it will be easier to add this back (and make it configurable).
I'll extend the new tutorial to cover using Sisu in Eclipse plug-ins, and schedule a work-item to add back the context utility class because it avoids the need to know about Sisu internals.
-- Cheers, Stuart
On 5 Sep 2013, at 17:03, Stuart McCulloch wrote: > Example: Bundle B1 declares class
Bean which uses interface I1 as
> one of its fields, but B1 has no implementation for I1. Bundle B2
> provides Impl1 which is an implementation of I1. B2 may depend on
B1
> (e.g. I1 is declared by B1 itself) or not (e.g. I1 is declared in
> bundle B0 known to both B1 and B2). I would like code in B1 to be
> able to instantiate class Bean and have its field of type I1
> injected with the implementation provided by B2.
Stuart, if you still want to have a
look at what I am doing,
and possibly give me a hint about what
is wrong, with respect to the desired behaviour that I described in my
previous email, I just pushed my sample workspace to github: https://github.com/giamma/sisu-test
To be used with Eclipse and the PDE.
B1 and B2 are PDE plug-in projects and
the repo contains a folder named target-platform whose content must be
used to define the PDE target platform.
B1 declares an explicit dependency toward
the Sisu extender bundle to ensure that the extender bundle is started
first.
B2 contains an activator that registers
a service listener observing Provider<Injector> in order to:
- obtain the injector created by the Sisu
extender for B2
- ensure that the code is executed only
after the Sisu extender has registered B2 in the bean locator
The sample code in the service listener
shows that:
- B1 injector cannot locate the
implementation class provided by B2
- B2 injector can locate
the implementation class provided by B2
- The locator obtained from B1
injector via injection in the B1 activator cannot instantiate the
implementation class
- The locator obtained from B2
injector via injection can instantiate the implementation class
- The two locators are not the
same, nor equal in the Java sense.
Thanks, I'll take a look this evening - having two locator instances is odd and is probably causing the other issues GianMaria.
_______________________________________________ sisu-users mailing list sisu-users@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/sisu-users
|