That looks like "notabug" to me. In those examples it's not just the requested type that differs, but how it's bound as well:
*bind(ITestAop.class)*.to(TestAopImpl.class).in(Singleton.class);ITestAop test = injector.getInstance(ITestAop.class); vs. *bind(TestAopImpl.class)*.in(Singleton.class);ITestAop test = injector.getInstance(TestAopImpl.class); On Wednesday, 24 June 2015 10:35:24 UTC-4, Sam Berlin wrote: > > https://github.com/google/guice/issues/935 is open about the different > behaviors between requesting the interface vs requesting the impl... There > shouldn't be a difference in behavior, right? > > sam > > On Wed, Jun 24, 2015, 10:29 AM Tavian Barnes <[email protected] > <javascript:>> wrote: > >> https://github.com/google/guice/issues/888 describes the general issue >> and a potential workaround in Guice 4: if you requireExplicitBindings(), it >> will prevent linked bindings from "bubbling up." >> >> >> On Wednesday, 24 June 2015 02:05:37 UTC-4, Vyacheslav Rusakov wrote: >>> >>> >>> Thank you for answer. You forward me to right direction. I did simple >>> test and it appear that there is a thin moment: >>> >>> When you have: >>> bind(IBean.class).to(BeanImpl.class) >>> And you inject bean as IBean, then it will be created in parent(!) >>> injector. >>> >>> But it will create bean in child injector if implementation is also >>> binded. >>> bind(IBean.class).to(BeanImpl.class) >>> bind(BeanImpl.class) >>> >>> It would be interesting to know "the why" for such behaviour. >>> >>> >>> вторник, 23 июня 2015 г., 20:05:25 UTC+6 пользователь Tavian Barnes >>> написал: >>>> >>>> bind(SomeBean.class); >>>> >>>> in the child module will force it to stay there. >>>> >>>> On Tuesday, 23 June 2015 01:26:42 UTC-4, Vyacheslav Rusakov wrote: >>>>> >>>>> Hello, >>>>> >>>>> Test ng guice support creates implicit parent injector and creates >>>>> child injector for your module. So parent injector is out of my control. >>>>> >>>>> If bean has no specific dependencies to other beans in child injector >>>>> it would be created in parent injector, even if this bean is declared in >>>>> child injector's module. >>>>> I understand this behaviour is by design to solve probles with JIT. >>>>> But when such bean moves to parent injector, aop interceptors, defined >>>>> in child injector, can't affect such bean anymore. >>>>> >>>>> I know that common recomendation for such case is to disable JIT, but >>>>> I don't want to do it (too radical solution). >>>>> Is there any workaround to tie bean to child injector without >>>>> introduction of some dummy (anchor) dependency on it? >>>>> >>>> -- >> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at http://groups.google.com/group/google-guice. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/google-guice/fae348f1-ff15-473b-91d4-aa24dfb7903c%40googlegroups.com >> >> <https://groups.google.com/d/msgid/google-guice/fae348f1-ff15-473b-91d4-aa24dfb7903c%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/6e680db9-90e4-440e-9c96-37320a284412%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
