tree 414bd8dc9ba567066ae07f7e23916705bba8f33f
parent 94c2d2c6c53cef4785413575ca445a048414641e
author Christian Edward Gruber <cgruber@google.com> 1368670307 -0700
committer Christian Edward Gruber <cgruber@google.com> 1368670335 -0700

Fix http://code.google.com/p/google-guice/issues/detail?id=742 by having assistedinject fail if the target implementation class has a scop
ing annotation on it.  Scope annotations on assistedinject targets were always ignored by Guice, and allowing them on the classes led to lots of confusion when reading code.  The new behavior makes for much more readable code.

This could potentially cause runtime errors at injector creation time if you accidentally had scoping annotations on the implementation class.  The fix is just to remove that scoping annotation -- there will be no change in behavior, because the scope was ignored.

There is an extreme edge case where this change may cause a problem, but it creates sufficiently confusing code that we are OK with turning it into a failure: You used assistedinject yet had no assisted parameters, and sometimes injected the object directly and other times constructed it through the factory.  When injecting directly, it would adhere to the scope, but when constructing through the factory it would create a new instance every time.  ... If you *really* wanted this behavior, the workaround would be to bind using toConstructor in Scopes.NO_SCOPE to a named(unscoped) version of the class, which is also more expressive.  (But, more often than not, what you really wanted was to *not do this*.)

------------------
Manually Synced.
COMMIT=43242119