Skip to content
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

@ProvidedBy @Singleton doesn't work #251

Closed
gissuebot opened this issue Jul 7, 2014 · 7 comments
Closed

@ProvidedBy @Singleton doesn't work #251

gissuebot opened this issue Jul 7, 2014 · 7 comments

Comments

@gissuebot
Copy link

From limpbizkit on September 26, 2008 13:12:47

It should provide a single instance.

The rules for @ProvidedBy and annotations don't need to be the same as for
@ImplementedBy, where scoping conflicts could be problematic. For
@ProvidedBy the scopes don't conflict.

Original issue: http://code.google.com/p/google-guice/issues/detail?id=251

@gissuebot
Copy link
Author

From ori.schwartz on July 14, 2011 11:34:55

also for @RequestScoped. i assume @ProvidedBy doesn't work with any scope annotations and always uses NO_SCOPE?

a simple junit test is attached.

Attachment: gist
   ProvidedByScopeTest.java

@gissuebot
Copy link
Author

From Ben.Manes on September 17, 2013 14:00:22

Any chance this is fixed in Guice 4.0? Just ran into this for a servlet filter.

@birdmanmandbir
Copy link

From Ben.Manes on September 17, 2013 14:00:22

Any chance this is fixed in Guice 4.0? Just ran into this for a servlet filter.

It is still not fixed. I think it is because @Providedby have larger priority than @Singleton?

@GedMarc
Copy link

GedMarc commented Apr 27, 2020

isn't it an ordering thing?
@ProvidedBy is a lazy load provider, singletons with providers need to be registered during module creation as a new provided class?
If you are going eager singleton even more so...

@birdmanmandbir
Copy link

birdmanmandbir commented Apr 27, 2020

isn't it an ordering thing?
@ProvidedBy is a lazy load provider, singletons with providers need to be registered during module creation as a new provided class?
If you are going eager singleton even more so...

You're right, maybe we need a new provided class to deal with this situation 👍

@GedMarc
Copy link

GedMarc commented Apr 27, 2020

No I mean there are two types are singletons, -
But either way the outcome is the same, so you can't use @ProvidedBy for singletons..
this seems a very by design item.

@birdmanmandbir
Copy link

No I mean there are two types are singletons, -
But either way the outcome is the same, so you can't use @ProvidedBy for singletons..
this seems a very by design item.

When we use @ProvidedBy, bind(Class1.class).in(Scopes.SINGLETON); is required to get singleton
When we use @Singleton, guice will create a singleton provider to give a singleton,
So if we both have @ProvidedBy and @Singleton, only @ProvidedBy is used by guice so we can't get singleton without ).in(Scopes.SINGLETON);

Am I understanding it correctly?

And I also write more test cases:
ProvidedByScopeTest.zip

birdmanmandbir pushed a commit to birdmanmandbir/guice that referenced this issue May 3, 2020
Solve issue google#251 and add corresponding test for it
Need consider scope annotation in ProvidedBy handling
copybara-service bot pushed a commit that referenced this issue Apr 21, 2023
…ProvidedBy when using the @ProvidedBy as the provider.

Notably, this does *not* change things to allow scoping annotations on interfaces or abstract classes (even though theoretically we could, because the @ProvidedBy will be instantiating it). Scopes on abstract classes|interfaces will still throw an exception about the scope being misplaced.

Fixes #251 and fixes #1319.

PiperOrigin-RevId: 525525327
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants