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.
