Introduce predefined composed annotations in core Spring [SPR-13442]

[spring-projects-issues]

Sam Brannen opened SPR-13442 and commented

Status Quo

Spring Framework 4.2 introduced support for explicit attribute overrides in meta-annotations via the new @AliasFor annotation. This new support makes it possible to include a set of predefined composed annotations in several modules of the Spring Framework.

---

Spring Composed

For the time being, the Spring team is using the spring-composed project as a playground for trying out new ideas with regard to what kinds of predefined composed annotations Spring should support.

Feedback is welcome!

---

Candidates for Inclusion

The following candidates are for inclusion in the Spring Framework.

• @GetMapping, @PostMapping, @PutMapping, @DeleteMapping, & @PatchMapping, for standard Spring MVC controller methods
• @ApplicationScope, @SessionScope, @RequestScope

---

Possible Candidates for Inclusion

The following candidates are possible for inclusion in the Spring Framework based on early feedback.

• @HeadMapping, @OptionsMapping, & @TraceMapping for standard Spring MVC controller methods
• @GetResource, @PostResource, @PutResource, @DeleteResource etc. for generic REST-based Spring MVC controller methods with preconfigured response statuses
• @TransactionalService, @TransactionalComponent, @TransactionalRepository
• @SingletonScope, @PrototypeScope, @GlobalSessionScope

---

Unlikely Candidates for Inclusion

The following candidates are unlikely for inclusion in the Spring Framework based on early feedback.

• @GetJson, @GetXml, etc. for opinionated REST-based Spring MVC controller methods
• @TransactionalController, @TransactionalRestController

---

Deliverables

1. Determine the set of predefined composed annotations to introduce.
2. Create new issues to address individual groups of composed annotations.
3. Implement, test, and document the new predefined composed annotations.

---

Affects: 4.2 GA

Issue Links:

• Custom @RequestMapping annotations [SPR-12296] #16901 Custom @RequestMapping annotations
• Use AnnotatedElementUtils instead of AnnotationUtils wherever feasible [SPR-13440] #18020 Use AnnotatedElementUtils instead of AnnotationUtils wherever feasible
• Support @ResponseStatus as a merged composed annotation [SPR-13441] #18021 Support @ResponseStatus as a merged composed annotation
• Introduce common composed annotations for @RequestMapping [SPR-13992] #18565 Introduce common composed annotations for @RequestMapping
• Introduce common composed annotations for web scopes [SPR-13993] #18566 Introduce common composed annotations for web scopes
• Document Spring Annotation Programming Model in the Wiki [SPR-11515] #16140 Document Spring Annotation Programming Model in the Wiki
• Support @CrossOrigin as a merged composed annotation [SPR-13468] #18047 Support @CrossOrigin as a merged composed annotation
• Support @Cache* as merged composed annotations [SPR-13475] #18054 Support @Cache* as merged composed annotations

7 votes, 17 watchers

[spring-projects-issues]

Marcel Overdijk commented

I especially like the @Get, @Post, @Put, @Delete annotations.
They are still general purpose but very useful. Hope at least these would even be backported to 4.2.x.

[spring-projects-issues]

Sam Brannen commented

Hi Marcel Overdijk,

Glad you like them!

Keep in mind that it's easy to implement these composed annotations on your own project, even if we don't backport them to 4.2.x.

Actually, that's how this whole thing started. I created @Get, etc. for my own demo project, and spring-composed grew from there. ;)

So if you want to use one of the proposed annotations, you can always just copy-n-paste the code into your own project or... since yesterday, add a dependency on org.springframework.composed:spring-composed:1.0.0.BUILD-SNAPSHOT.

Regards,

Sam

[spring-projects-issues]

Marcel Overdijk commented

Sure, can easily copy them, or indeed as I have done yesterday added the dependency.
But as they are so siple and the Spring 4.2 infrastructure already supports it I thought it would be no big thing to backport them.
Having build-snapshot deps in project is not so nice :-)

[spring-projects-issues]

Sam Brannen commented

Having build-snapshot deps in project is not so nice

True... but Spring Composed is still a playground for the time being while we work out what kinds of annotations (and default attribute values) make sense and while we gather input from the community on what types of predefined composed annotations to support. So if you have further ideas, please let us know.

We are currently not planning on backporting such annotations to 4.2.x; however, if there is enough interest from the community we will take it into consideration.

[spring-projects-issues]

Juergen Hoeller commented

From my perspective, the main problem is that there are almost unlimited combinations possible, creating more confusion than clarity for the casual observer. However, the main benefit of selecting composed annotations into Spring Framework proper is guidance, with a smaller set of annotations delivering a much better job in that respect, so it's a tough balance to find. For that kind of effort, the 4.3 timeframe is ideal... and 4.3 RC1 is planned for early March, so it's not far away at all.

If there is obvious low-hanging fruit in specific corners of the framework, we may add an annotation or two right away in the 4.2.x line. However, for mainstream usage such as request mappings or bean scoping, we'll have to leave some room for further discussions, in particular about naming and about the specific default values. We only have one shot here: once an annotation is official, we have to live with its design; even the slightest variation would require yet another new annotation.

Juergen

[spring-projects-issues]

Tomoyuki Ikeya commented

In my opinion, @XxxScope is better than @XxxScoped.
@XxxScoped may have derived from CDI's annotations,
but some @XxxScope annotations have already defined in other spring projects. (@StepScope/@JobScope in Spring Batch, @RefreshScope in Spring Cloud)
I think it's more familiar for existing Spring users.

[spring-projects-issues]

Juergen Hoeller commented

On a related note to scope annotation naming (which I agree with), we should also have our new web scope annotations default to proxy mode TARGET_CLASS, analogous to the existing scope variants in Spring Cloud and Spring Batch, while still allowing for a choice of proxy modes via a proxyMode attribute.

Juergen

[spring-projects-issues]

Sam Brannen commented

See #18565 for common composed annotations for @RequestMapping.

[spring-projects-issues]

Sam Brannen commented

FYI: anyone interested in the currently proposed composed annotations for @RequestMapping can take a look at the following pull request:

#981

[spring-projects-issues]

Sam Brannen commented

See #18566 for common composed annotations for web scopes.

[spring-projects-issues]

Sam Brannen commented

FYI: anyone interested in the currently proposed composed annotations for web scopes can take a look at the following pull request:

#982

[spring-projects-issues]

Sam Brannen commented

Resolving this issue as Complete since #18565 and #18566 cover all composed annotations currently targeted for inclusion in Spring Framework 4.3.

[spring-projects-issues]

Tim commented

I don't agree with the intention of this. Features should not be introduced into a framework just to take advantage of a new capability.
The spring framework should be as clean and concise as possible, and if there is something missing - like an annotation - then add it. The fact it is being added by the use of a composed annotation is mostly not relevant.
There is a potential downside to using composed annotations which is that the hierarchy of composition could get quite complex, eg: A includes B which include C which includes D. So perhaps the framework should try as hard as possible to keep the hierarchy flat, which leaves the projects using the framework, more freedom to compose annotations which will not be too complex.