You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
1) Module binds Foo.
2) Foo is @ImplementedBy(FooImpl.class)
3) FooImpl class has a dependency on Bar
4) Bar is @ImplementedBy(AutoBar.class)
5) Module binds Bar to ExplicitBar.class
When figuring out the @ImplementedBy for FooImpl, it's creating a JIT binding for AutoBar too, and the getExistingBinding check when doing ExplicitBar sees AutoBar and fails.
InjectorImpl.createUninitializedBinding is called by BindingProcessor.visit(UntargettedBinding). It ends up checking for @ImplementedBy (and @ProvidedBy) and creates JIT bindings for them. The JIT bindings then lead to problem two...
Problem Two
If an untargetted binding is @ImplementedBy, its dependencies need to be eagerly creatable. That is, if
1) Foo is @ImplementedBy(FooImpl.class)
2) FooImpl has a dependency on Bar
3) Bar is explicitly bound in a module AFTER bind(Foo.class) is written
then FAIL, because Bar can't be created when constructing the JIT binding for FooImpl.
fixed in r1526 & test cases added. probably could be cleaned up a bit.. but i think any decent solution is going to require this second pass over the elements.
From sberlin on March 10, 2011 18:29:13
Problem One
1) Module binds Foo.
2) Foo is
@
ImplementedBy(FooImpl.class)3) FooImpl class has a dependency on Bar
4) Bar is
@
ImplementedBy(AutoBar.class)5) Module binds Bar to ExplicitBar.class
When figuring out the
@
ImplementedBy for FooImpl, it's creating a JIT binding for AutoBar too, and the getExistingBinding check when doing ExplicitBar sees AutoBar and fails.InjectorImpl.createUninitializedBinding is called by BindingProcessor.visit(UntargettedBinding). It ends up checking for
@
ImplementedBy (and@
ProvidedBy) and creates JIT bindings for them. The JIT bindings then lead to problem two...Problem Two
If an untargetted binding is
@
ImplementedBy, its dependencies need to be eagerly creatable. That is, if1) Foo is
@
ImplementedBy(FooImpl.class)2) FooImpl has a dependency on Bar
3) Bar is explicitly bound in a module AFTER bind(Foo.class) is written
then FAIL, because Bar can't be created when constructing the JIT binding for FooImpl.
Original issue: http://code.google.com/p/google-guice/issues/detail?id=614
The text was updated successfully, but these errors were encountered: