Skip to content

Introduce @SingletonScope and @PrototypeScope composed annotations #22574

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

Closed
wants to merge 1 commit into from

Conversation

bojanv55
Copy link

Since there are already: @ApplicationScope, @requestScope and @SessionScope (here). In order to be consistent, I guess it would be nice to include this 2 core annotations?

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Mar 12, 2019
@sbrannen sbrannen added in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement for: team-attention labels Mar 12, 2019
@sbrannen
Copy link
Member

I initially proposed those two composed annotations in #18022, but the Spring team decided against inclusion of them at the time.

Labeling with "for: team-attention" to discuss if the team would like to consider introducing such scope annotations now.

@sbrannen sbrannen changed the title Added prototype and singleton annotations Introduce @SingletonScope and @PrototypeScope composed annotations Mar 12, 2019
@sbrannen sbrannen self-assigned this Mar 12, 2019
@sbrannen sbrannen added status: declined A suggestion or change that we don't feel we should currently apply and removed for: team-attention status: waiting-for-triage An issue we've not yet triaged or decided on labels Mar 12, 2019
@sbrannen
Copy link
Member

After some internal discussions, we have decided that we do not wish to introduce composed annotations for singleton and prototype scopes, since we feel that they do not add much value over @Scope("singleton") and @Scope("prototype") declarations, especially since singleton is the default.

You are of course free to implement such composed annotations and use them in your own projects if you feel that they add value for your team.

Thanks anyway for the PR!

@sbrannen sbrannen closed this Mar 12, 2019
@bojanv55
Copy link
Author

After some internal discussions, we have decided that we do not wish to introduce composed annotations for singleton and prototype scopes, since we feel that they do not add much value over @Scope("singleton") and @Scope("prototype") declarations, especially since singleton is the default.

You are of course free to implement such composed annotations and use them in your own projects if you feel that they add value for your team.

Thanks anyway for the PR!

For singleton, you can say that it is default so there - it makes sense to leave it out (the only reason for inclusion would be consistency). But for prototype, I guess you would get compile time safety since otherwise you can always write something like @Scope("prototipe") and have program start without any problem until actual injection..

@hannah23280
Copy link

hannah23280 commented Nov 13, 2023

Truely hope this can be reopened again. I agree it might not add value, but at least it ensures consistency. Easy for learner to grasp it. And help to shorten the "syntax".

And beside these 2, also wish there are @WebSocketScope. To make things worse, my understanding is that defining websocket scope would look like this currently
@Scope(scopeName="websocket", proxyMode=ScopedProxyMode.TARGET_CLASS) and defining Singleton/Prototype scope look like this
@Scope(value=ConfigurableBeanFactory.SCOPE_SINGLETON).

Inconsistent again, as one use scopeName attribute, and the other use value attribute

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: declined A suggestion or change that we don't feel we should currently apply type: enhancement A general enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants