Hey,

I'm just trying to get my head around the following problem. I'm working on 
a framework which exposes SPI to other developers.
The current structure (and it's injector structure) is like the following:

* Root (root injector)
** services (child injector)
*** operations (child child injector)

Each level only knows about the class objects for the level below (eg. a 
service only knows about which classes implement it's operations).
The initial thought was to pass injectors down the chain to instantiate and 
inject dependencies for these classes (eg. @Inject Injector) and then 
creating the child injectors.
While this works fine, I just stumbled on one problem which revealed that 
the whole hierarchy might not be as easy as I thought.
Let's say the root injector provides A, a Service depends on nothing but 
provides B and one of its operations depends on A and B.
When passing down the Injector to the operation, the operation only sees A 
but not B as the service doesn't depend on anything and thus the root 
injector get's used and injected.
Adding @Inject A to the service resolves the problem but that's actually a 
little but too much trickery and forces service implementations to always 
know what parent dependencies they'd need to depend on in order to get the 
right injector.

While this behaviour is intentional as far as I read the Guice docs, I 
wondered what alternatives would make sense to build up the hierarchy of 
dependencies in order to create the operations.

Thanks,
  Benjamin

-- 
You received this message because you are subscribed to the Google Groups 
"google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to