Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # 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
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
3 participants