And why this message comes aswell:
Unable to create binding for
com.netdesign.dao.cisco.v7.uccx.CiscoUCCX7WallBoardDataProvider. It
was already configured on one or more child injectors or private
modules
bound at
com.netdesign.dao.cisco.general.uccx.CiscoUCCXModule.configure(CiscoUCCXModule.java:87)
bound at
com.netdesign.dao.cisco.general.uccx.CiscoUCCXModule.configure(CiscoUCCXModule.java:86)
If it was in a PrivateModule, did you forget to expose the binding?
Yes it is in a PrivateModule but I did expose it in the parent injector..
2011/10/20 nino martinez wael <[email protected]>:
> Ok, so back to the original question.
>
> Why am I getting the exception that the binding could not be created .
>
> "It was already configured on one or more child injectors or private"
>
> So thats when the modules are being booted. One of the submodules are
> getting this when it should be injected from the parent..?
>
>
>
> 2011/10/20 Sam Berlin <[email protected]>:
>> In that case, you'd just do what you're doing -- use
>> Injector.createChildInjector and build up your modules at runtime. They'd
>> behave effectively like PrivateModules (child bindings are cordoned off from
>> siblings or the parent), with the caveat that you can't expose things from
>> the child to the parent. You'd get the behavior where your child's module
>> can base its behavior on things bound in the parent module, because the
>> child module is being used at runtime instead of injector-creation-time.
>> sam
>>
>> On Thu, Oct 20, 2011 at 2:06 PM, nino martinez wael
>> <[email protected]> wrote:
>>>
>>> I am literally meaning this:
>>>
>>> "Are things bound in the parent module accessible in the private
>>> module -- as in the module itself"
>>>
>>> This is currently what I am doing now with the injectors and
>>> childinjectors.. Since the logic are that childs only can depend on
>>> parents. Im running a very dynamic configuration environment, where
>>> modules are discovered at runtime, thats why it has to be this way.
>>>
>>> regards Nino
>>>
>>> 2011/10/20 Sam Berlin <[email protected]>:
>>> > Yes, stuff from parent modules are accessible to things bound in the
>>> > private
>>> > modules. Things bound in private modules are not accessible to things
>>> > bound
>>> > in parent modules unless the bindings are exposed.
>>> > As far as the question, "What if I need stuff that are setup in parent
>>> > module injected in the private module?" -- This can be a trick
>>> > question.
>>> > If you literally mean, "Are things bound in the parent module
>>> > accessible in
>>> > the private module -- as in the module itself" then the answer is no.
>>> > If
>>> > you mean are things from the parent module available to objects setup
>>> > through the private module's bindings, then the answer is yes.
>>> > For illustration:
>>> > ParentModule {
>>> > configure() {
>>> > bind(Foo.class);
>>> > install(new PrivateModule() {
>>> > @Inject Foo foo;
>>> > configure() {
>>> > if (foo.toggle()) {
>>> > bind(Bar.class);
>>> > } else {
>>> > bind(Baz.class);
>>> > }}});}} // lots of closing braces
>>> > The above doesn't work. Nothing can be injected into Modules or
>>> > PrivateModules, because Modules are how Guice figures out what can be
>>> > injected in the first place. You have a chicken/egg problem if you want
>>> > to
>>> > inject things into Modules.
>>> > BUT! ... if you remove the @Inject and the if/else from the
>>> > PrivateModule,
>>> > and you just want to see if Bar can have an @Inject Foo in it, the
>>> > answer is
>>> > yes.
>>> > sam
>>> > On Thu, Oct 20, 2011 at 1:11 PM, nino martinez wael
>>> > <[email protected]> wrote:
>>> >>
>>> >> Aha! so if I create a private module in a module then it will act as a
>>> >> childinjector and get stuff from the parent module acesible to it?
>>> >> What if I need stuff that are setup in parent module injected in the
>>> >> private module?
>>> >>
>>> >> 2011/10/20 Sam Berlin <[email protected]>:
>>> >> > PrivateModules are effectively child injectors. There's no way to
>>> >> > explicitly create a "child injector" within a Module, PrivateModule
>>> >> > is
>>> >> > the
>>> >> > only tool you're given. So it's easiest to illustrate within Modules
>>> >> > using
>>> >> > PrivateModules. Creating child injectors at runtime follows the same
>>> >> > rules.
>>> >> > sam
>>> >> >
>>> >> > On Thu, Oct 20, 2011 at 12:47 PM, nino martinez wael
>>> >> > <[email protected]> wrote:
>>> >> >>
>>> >> >> Although in your text you dont mention childinjectors... only
>>> >> >> submodules?
>>> >> >>
>>> >> >> 2011/10/20 nino martinez wael <[email protected]>:
>>> >> >> > I think its exactly what you are writing I am doing thats why i
>>> >> >> > don't
>>> >> >> > understand the error. I don't even bind more than one interface of
>>> >> >> > the
>>> >> >> > same type on any level..
>>> >> >> >
>>> >> >> > 2011/10/20 Sam Berlin <[email protected]>:
>>> >> >> >> Do you have a concrete example of a few bindings and how you want
>>> >> >> >> them
>>> >> >> >> organized? I'm having trouble understanding what you're going
>>> >> >> >> for.
>>> >> >> >> Here's some examples of visibility with private modules &
>>> >> >> >> bindings:
>>> >> >> >> ParentModule binds Foo & PrivateSubModuleA & PrivateSubModuleB
>>> >> >> >> PrivateSubModuleA binds Bar, Baz & PrivateSubSubModuleA,
>>> >> >> >> exposes Baz
>>> >> >> >> PrivateSubSubModuleA binds & exposes Buz
>>> >> >> >> PrivateSubModuleB binds Bar, Boz & PrivateSubSubModuleB,
>>> >> >> >> exposes Boz
>>> >> >> >> PrivateSubSubModuleB binds & exposes Buz
>>> >> >> >> Foo cannot be bound in any module other than ParentModule because
>>> >> >> >> all
>>> >> >> >> modules already see Foo. Foo can be injected by anything, since
>>> >> >> >> it's
>>> >> >> >> available everywhere.
>>> >> >> >> Bar can be bound in both PrivateSubModuleA & PrivateSubModuleB
>>> >> >> >> because
>>> >> >> >> they
>>> >> >> >> are sibling private modules and the binding isn't exposed.
>>> >> >> >> Bar cannot
>>> >> >> >> be
>>> >> >> >> bound in PrivateSubSubModuleA or PrivateSubSubModuleB, because
>>> >> >> >> their
>>> >> >> >> parent
>>> >> >> >> modules have Bar bound. Foo cannot inject Bar, because it isn't
>>> >> >> >> visible to
>>> >> >> >> things from ParentModule.
>>> >> >> >> Baz cannot be bound in any module other
>>> >> >> >> than PrivateSubModuleA because
>>> >> >> >> all
>>> >> >> >> modules already see Baz (since it's exposed to ParentModule).
>>> >> >> >> Baz can
>>> >> >> >> be
>>> >> >> >> injected by anything, since it's available
>>> >> >> >> everywhere.
>>> >> >> >> Buz can be bound in the SubSub modules, because they are
>>> >> >> >> effectively
>>> >> >> >> the
>>> >> >> >> same namespace as Bar -- visible to the Sub & SubSub modules
>>> >> >> >> only.
>>> >> >> >> Foo cannot inject Buz, because it isn't visible to things from
>>> >> >> >> ParentModule.
>>> >> >> >> Boz cannot be bound in any module other than PrivateSubModuleB
>>> >> >> >> because
>>> >> >> >> all
>>> >> >> >> modules already see Boz (since it's exposed to ParentModule).
>>> >> >> >> Boz can
>>> >> >> >> be
>>> >> >> >> injected by anything, since it's available everywhere.
>>> >> >> >>
>>> >> >> >> sam
>>> >> >> >>
>>> >> >> >> On Thu, Oct 20, 2011 at 11:05 AM, nino martinez wael
>>> >> >> >> <[email protected]> wrote:
>>> >> >> >>>
>>> >> >> >>> I have this setup
>>> >> >> >>>
>>> >> >> >>> InjectorA-ModuleA-InjectorB-ModuleB-InjectorC-ModuleC-Final
>>> >> >> >>> injector
>>> >> >> >>>
>>> >> >> >>> \----ModuleD--/
>>> >> >> >>>
>>> >> >> >>> On the B level there are multiple Modules which all are private
>>> >> >> >>> however they possibly expose a interface that possible used in
>>> >> >> >>> one
>>> >> >> >>> of
>>> >> >> >>> the multiple modules on layer C. However I get this message on
>>> >> >> >>> the
>>> >> >> >>> c
>>> >> >> >>> level when it tries to inject the interface from B level:
>>> >> >> >>>
>>> >> >> >>> Unable to create binding for
>>> >> >> >>>
>>> >> >> >>> com.netdesign.remedy.provider.RemedyWallboardDataProviderInterface.
>>> >> >> >>> It
>>> >> >> >>> was already configured on one or more child injectors or private
>>> >> >> >>> modules
>>> >> >> >>>
>>> >> >> >>> will private module only expose to siblings or does it work on
>>> >> >> >>> children
>>> >> >> >>> aswell?
>>> >> >> >>>
>>> >> >> >>> regards Nino
>>> >> >> >>>
>>> >> >> >>> --
>>> >> >> >>> You received this message because you are subscribed to the
>>> >> >> >>> Google
>>> >> >> >>> Groups
>>> >> >> >>> "google-guice" group.
>>> >> >> >>> To post to this group, send email to
>>> >> >> >>> [email protected].
>>> >> >> >>> To unsubscribe from this group, send email to
>>> >> >> >>> [email protected].
>>> >> >> >>> For more options, visit this group at
>>> >> >> >>> http://groups.google.com/group/google-guice?hl=en.
>>> >> >> >>>
>>> >> >> >>
>>> >> >> >> --
>>> >> >> >> You received this message because you are subscribed to the
>>> >> >> >> Google
>>> >> >> >> Groups
>>> >> >> >> "google-guice" group.
>>> >> >> >> To post to this group, send email to
>>> >> >> >> [email protected].
>>> >> >> >> To unsubscribe from this group, send email to
>>> >> >> >> [email protected].
>>> >> >> >> For more options, visit this group at
>>> >> >> >> http://groups.google.com/group/google-guice?hl=en.
>>> >> >> >>
>>> >> >> >
>>> >> >>
>>> >> >> --
>>> >> >> You received this message because you are subscribed to the Google
>>> >> >> Groups
>>> >> >> "google-guice" group.
>>> >> >> To post to this group, send email to [email protected].
>>> >> >> To unsubscribe from this group, send email to
>>> >> >> [email protected].
>>> >> >> For more options, visit this group at
>>> >> >> http://groups.google.com/group/google-guice?hl=en.
>>> >> >>
>>> >> >
>>> >> > --
>>> >> > You received this message because you are subscribed to the Google
>>> >> > Groups
>>> >> > "google-guice" group.
>>> >> > To post to this group, send email to [email protected].
>>> >> > To unsubscribe from this group, send email to
>>> >> > [email protected].
>>> >> > For more options, visit this group at
>>> >> > http://groups.google.com/group/google-guice?hl=en.
>>> >> >
>>> >>
>>> >> --
>>> >> You received this message because you are subscribed to the Google
>>> >> Groups
>>> >> "google-guice" group.
>>> >> To post to this group, send email to [email protected].
>>> >> To unsubscribe from this group, send email to
>>> >> [email protected].
>>> >> For more options, visit this group at
>>> >> http://groups.google.com/group/google-guice?hl=en.
>>> >>
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> > Groups
>>> > "google-guice" group.
>>> > To post to this group, send email to [email protected].
>>> > To unsubscribe from this group, send email to
>>> > [email protected].
>>> > For more options, visit this group at
>>> > http://groups.google.com/group/google-guice?hl=en.
>>> >
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "google-guice" group.
>>> To post to this group, send email to [email protected].
>>> To unsubscribe from this group, send email to
>>> [email protected].
>>> For more options, visit this group at
>>> http://groups.google.com/group/google-guice?hl=en.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "google-guice" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected].
>> For more options, visit this group at
>> http://groups.google.com/group/google-guice?hl=en.
>>
>
--
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-guice?hl=en.
