Hrm, the thing with the suggestion of switching to Providers is that the
broker won't even have a binding to a provider, so I'm pretty sure (haven't
tried yet) that it will fail out saying that it doesn't know how to create
that Provider.
I thought about creating separate methods for the different node types, but
I'd rather not tie the API to the set of the nodes that exist. I'd prefer
to have the system have the freedom to change around how it structures and
thinks about nodes without the extensions having to worry about them.
I'll try the Provider out tomorrow and see if that fixes it and if that
doesn't work (and there aren't other suggestions), I'll start adjusting
everything to be under one big injector.
--Eric
On Thu, Sep 19, 2013 at 9:12 PM, Nate Bauernfeind <
nate.bauernfe...@gmail.com> wrote:
> 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 <
> nate.bauernfe...@gmail.com> 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 <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.
