New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multibinder Bindings Don't Always Respect Singleton Scope #791
Comments
|
From sberlin on December 11, 2013 10:15:19 Use a separate bind(B.class).in(Singleton.class) to make this work. What is happening is that you're making linked binding a singleton, but not the underlying binding a singleton. The same thing would happen if you did: Status: WorkingAsIntended |
|
Is there no way around this ? (e.g is it unreasonable to not want to explicitly bind using |
|
The best way to make FooImpl not injectable is to make it package-private, so others can't refer to it. |
|
Sure; that works if I have a Module in that same package. I'm dealing with a ball of legacy code, and can't really do that (or ensure that everyone does it, anyway). That said, the extra binding is also probably no big deal, but I have no way of checking (in plugin-based environment, my only option now is to let the bindings fail at runtime, and it might not fail for everyone) |
|
Sam and OP, I got this to work this way: (with help from @tmattsson) replaced by this: makes it work as we expect. WDYT ? |
From nachtrabe on December 11, 2013 13:10:31
Description of the issue: When using the multibinder, if you use
binder.addBinding().to(B.class).in(Singleton.class);it will not enforce the singleton nature on that object, but using the@`Singleton` annotation directly will. Steps to reproduce: 1. Create a Multibinder.newSetBinder instance with an interface. 2. Bind an implementation using `.in(Singleton.class)`. 3. Bind another implementation annotated with@Singleton.4. Inspect that the instances retrieved are not singletons in the cases where
.in(Singleton.class)was used, but are in the cases where ``@Singletonwas used.Expected behavior:
- I'd expect for .in(Singleton.class) to work, to not be exposed, or to throw an exception.
The attached tests illustrate the problem:
getInstance_ofSet_ContainsBandgetInstance_ofB_IsIdenticalboth fail under both Guice 3.0 and Guice 4.0-beta.Attachment: gist
GuiceTest.java
Original issue: http://code.google.com/p/google-guice/issues/detail?id=791
The text was updated successfully, but these errors were encountered: