Open GoogleCodeExporter opened 9 years ago
Yup, these are known limitations of AssistedInject. AssistedInject for Guice
1.0 is a fairly naive extension, and
unfortunately Guice 1.0 doesn't have hooks for it to do much better
(assistedinject only uses Guices' public API).
There are workarounds - always use explicit bind statements for
assistedinject's dependencies.
Original comment by limpbizkit
on 24 Jul 2008 at 7:41
Original comment by limpbizkit
on 24 Jul 2008 at 7:41
Are you saying this limitation only applies to guice-1.0? Is this limitation
fixed in
guice-trunk?
Unfortunately, using explicit bind statements gets out of hand very quickly.
It's
easy for default constructors but if you need to explicitly bind Providers and
instances you run into problems there are any cyclic dependencies or very deep
dependency graphs that Guice handles on your behalf very nicely.
Seeing how the guice-1.0 implementation is naive, can we not simply remove this
check
and let it break later on if the type is not injectable? Wouldn't this yield the
desired flexibility at a cost of harder-to-read error messages?
Original comment by gili.tza...@gmail.com
on 24 Jul 2008 at 7:53
I just tried hard-coding paramCanBeInjected() to return true and it seems to
work
just fine. If injection is allowed it proceeds properly, if not Guice gives its
standard error about not knowing how to construct X.
Is this a possible solution?
Original comment by gili.tza...@gmail.com
on 24 Jul 2008 at 8:06
Original issue reported on code.google.com by
gili.tza...@gmail.com
on 24 Jul 2008 at 7:24