Hrm, Just to explain the issue a little better, I wrote up a toy code example that shows what's happening. I should've done this from the beginning, sorry I didn't:
https://gist.github.com/cheddar/6639345 The issue is that it is exceptioning out when building the brokInj, even though at the end of the day the brokInj actually does have all the bindings it needs to do it's job (return the Names.named("Broker") Map). Hopefully that helps clarify what I'm dealing with. --Eric On Fri, Sep 20, 2013 at 9:29 AM, Mike Grove <m...@clarkparsia.com> wrote: > fwiw, i used almost the exact same pattern, using the SPI to load guice > modules at startup, but i didnt run into this issue because i have multiple > injectors that are only responsible for their part of the app, and the > module interfaces are very targeted so we don't run into the kinds of > problems you're hitting where an overloaded module has all the bindings for > one thing, or the other, but not both. > > you might consider finer-grained modules. we get a lot of mileage out of > Modules.override and installing modules w/in other modules as start time. > > > > On Thu, Sep 19, 2013 at 3:39 PM, Eric Tschetter <eched...@gmail.com>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 google-guice+unsubscr...@googlegroups.com. >> To post to this group, send email to google-guice@googlegroups.com. >> 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 google-guice+unsubscr...@googlegroups.com. > To post to this group, send email to google-guice@googlegroups.com. > 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 google-guice+unsubscr...@googlegroups.com. To post to this group, send email to google-guice@googlegroups.com. Visit this group at http://groups.google.com/group/google-guice. For more options, visit https://groups.google.com/groups/opt_out.
