Ahhh, ok, yeah, that definitely does work. But I agree that it's pretty firmly in workaround land :). As a rule, I generally do not allow actual business logic classes to depend on anything in Guice other than annotations.
For what it's worth, I did the exercise of switching everything to having one Injector and all of the modules and, in the end, I actually like it better than the original setup I had. I now reference all of the modules a lot less throughout the code, and each of the actual main() methods is much more succinct about what it is doing different from the others (whereas before, they shared a lot of the same modules). --Eric On Fri, Sep 20, 2013 at 11:26 AM, Nate Bauernfeind < [email protected]> wrote: > My suggestion was to do this to your HistoricalExtension constructor: > > @Inject > public HistoricalExtension( > Injector injector > ) > { > this.val = injector.getInstance(CharSequence.class); > } > > > Which results in output of this: > =========== > 3 => WHOZI > howdy => HOWDY > |||||||||||| > > ============ > howdy => HOWDY > |||||||||||| > > > On Fri, Sep 20, 2013 at 10:34 AM, Eric Tschetter <[email protected]>wrote: > >> 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 <[email protected]> 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 <[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. >>> >> >> -- >> 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. > -- 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.
