Skip to content

Consider providing specific @RequestScoped etc annotations [SPR-5597] #10268

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
spring-projects-issues opened this issue Mar 22, 2009 · 5 comments
Assignees
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

Comments

@spring-projects-issues
Copy link
Collaborator

Chris Beams opened SPR-5597 and commented

Currently, StandardScopes is available in the .context.annotation package, after having been moved over from .context.java.

This may not be the best place for it; decide on better packaging and move it accordingly.

Also, consider updating references throughout the codebase to BeanDefintion.SCOPE_SINGLETON to refer to StandardScopes.SINGLETON, etc.

At any rate, the goal is to place this class prominently in the 3.0 packaging and advertise its use in the reference documentation, esp. in conjunction with the @Scope annotation.


1 votes, 2 watchers

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Since 3.0 M3, we have the option of meta-annotating scopes: either on stereotypes or on custom scope annotations. This generally allows for custom @RequestScoped, @SessionScoped etc annotations now, simply meta-annotating those with @Scope("request") / @Scope("session"). We could also provide such specific annotations out of the box, at least for the standard scopes that we're supporting. This looks more attractive than the StandardScopes pseudo-enum to me, in particular since those specific annotations may live in the modules that actually define those 'standard' scopes (e.g. in the web module for the request and session scopes).

Juergen

@spring-projects-issues
Copy link
Collaborator Author

Chris Beams commented

This meta-annotation approach to scoping works in conjunction with both @Component and @Bean?

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Yes, defining a scope through meta-annotations works for @Component and @Bean - at least in 3.0 RC1.

I'll keep this issue open for 3.1 where we'll be introducing first-class conversation support as well.

Juergen

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Feb 25, 2011

Neale Upstone commented

I think meta-annotations ought to be consistent across the whole Spring Framework. It's a shame that Sun decided to have ElementType.TYPE include ANNOTATION_TYPE, as all Spring's TYPE annotations can be applied to other annotations, but Spring doesn't always look for them there. I've noted on #12483 that this could be consistent.

Perhaps Spring annotations could specify ANNOTATION_TYPE in addition to be clear to users of the annotation that it is supported as a meta annotation. We could also check for this in AnnotationUtils if there is good reason to exclude meta-annotation support from some TYPE targetted annotations...?

Would you welcome a patch (in fact a pull request against Chris's github repo)? I'm committed to JUnit 4.9 and Spring 3.1 get meta-annotations nailed and can back it up with the time needed.

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Closing groups of outdated issues. Please reopen if still relevant.

@spring-projects-issues spring-projects-issues added status: declined A suggestion or change that we don't feel we should currently apply type: enhancement A general enhancement in: core Issues in core modules (aop, beans, core, context, expression) labels Jan 11, 2019
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

No branches or pull requests

2 participants