Also, I might recommend allowing your extensions to implement two separate configuration methods -- one for the historical injector and the other for your broker injector.
Then, something like you're explaining would easily be "covered" or explained as a bug in the contract between your design and the extension. On Thu, Sep 19, 2013 at 9:10 PM, Nate Bauernfeind < [email protected]> wrote: > I think this is the easiest way to do this (written in Scala purely for > terseness): > > class A > class B @Inject() (a: A) > > class TestModule extends PrivateModule { > def configure() {} > > @Provides > def createB(a: Provider[A]): B = { > new B(a.get()) > } > } > > If you change Provider[A] to A you get the eager binding validation. Note, > you can still annotate your provider method as a Singleton. > > Additionally, you can let your B take in a Provider and have the needed > logic to error out if an instance of A is not available in your injected > class' constructor. > > Nate > > > On Thu, Sep 19, 2013 at 2:39 PM, Eric Tschetter <[email protected]>wrote: > >> Hello Guicers, >> >> I'm running into a bit of a problem that I was wondering if someone from >> the Guice community might have some great insight into how to deal with it. >> >> I have a project that is an open distributed analytical data store ( >> http://www.druid.io) and I've been guicifying it in order to better >> accommodate plugins. >> >> I'm basically using SPI to find instances of a "DruidModule" interface >> that I created in the classpath of extensions, I then add those modules >> into the main Guice injector and I'd added an external module to the >> system. Or, at least, that's the theory. >> >> This is generally working, however, I have a number of different node >> types that each have different object graph requirements. Right now, each >> node type creates its own injector with modules that build up only the >> object graph required by that node type. >> >> This is causing a problem for my extensions, because I'm only creating a >> single module in the extension, which can get added to any of the injectors >> on any of the processes. Specifically, I have a "broker" node and a >> "historical" node. The extension I'm working with is meaningful in both >> contexts, but only a subset of the classes are actually used on the >> "broker" node, while all of them are relevant to the "historical" node. >> >> The problem is, the one class that is only used on the historical node >> (i.e. it is bound by the module, but never instantiated on the broker >> node), depends on something that the broker node does not have a binding >> for. Even though the broker node never instantiates the thing that >> requires the missing binding, Guice still fails because, if it did need it, >> it wouldn't be there. >> >> I've been wondering if there's a way to actively turn off the checking >> there and force it to be lazy. I don't actually leverage Guice except in >> the bootstrap phase of my application, so I don't gain any extra benefit >> from how Guice enforces fail-fast behavior and thus the check right now is >> only serving as an annoyance :). >> >> The only other work-around I can see for this is to basically build one >> big Guice injector with full bindings for use across all node types. The >> only differentiation between the node types being the set of objects that >> actually get instantiated on startup. If I were to do that, I would work >> around this, but it would also open the door to having weird things >> accidentally instantiated at weird points, so I'm a little reluctant to do >> it. If this is the only option, I will switch to this model, just hoping >> there are other options as well. >> >> Does that all make sense? >> >> --Eric >> >> -- >> 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. >> > > -- 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.
