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 <eched...@gmail.com> 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 <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.
>
--
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.
