Reinstate support for legacy JSR-250 `@javax.annotation.ManagedBean` and JSR-330 `@javax.inject.Named` annotations

[YSavanier]

Overview

As asked, this is a copy paste of #33345.

This regression is done again in version 7: 949432c.

Original Text

With the migration to Jakarta annotations in 7.0, we switched to supporting @jakarta.annotation.ManagedBean and @jakarta.inject.Named annotations for component scanning and component name lookups.

To better assist projects in the migration to Spring 6+ and 7+, we should reinstate support for the legacy JSR-250 @javax.annotation.ManagedBean and JSR-330 @javax.inject.Named annotations so that existing compiled code will continue to work as expected.

Deliverables

• Support @javax.annotation.ManagedBean and @javax.inject.Named in ClassPathScanningCandidateComponentProvider#registerDefaultFilters(...).
• Support @javax.annotation.ManagedBean and @javax.inject.Named in AnnotationBeanNameGenerator#isStereotypeWithNameValue(...).
• Update tests.
• Update Javadoc.

Related Issues

• Retain support for legacy JSR-250 javax.annotation.PostConstruct/PreDestroy and JSR-330 javax.inject.Inject in addition to Jakarta EE 9 annotations #27444
• Reinstate dependency injection support for legacy JSR-250 @javax.annotation.Resource annotation #30695
• Reinstate support for legacy JSR-250 @javax.annotation.ManagedBean and JSR-330 @javax.inject.Named annotations #31090
• Reinstate qualifier support for legacy JSR-330 @javax.inject.Named annotation #33345

[jhoeller]

This is no accidental regression since we intentionally removed JSR-250 (once again) as part of our Jakarta EE 11 baseline.

I wonder what keeps you relying on the old JSR-250 annotations at this point? Back with 6.x, the migration scenario was more immediate, but now we're two generations of Spring and three generations of Jakarta EE beyond the original use of JSR-250...

[YSavanier]

Because like many on this planet we manage big legacy apps whose depends on customs library using javax namespace.

Moving from javax.servlet to jakarta.servlet is already a big hurdle for those but we are still doing the job since this is the main issue threatening them here.

For the many others imported classes we rely on that are using the javax namespace, we will have to leave those libs using both javax and jakarta ns in their codebase since we can't possibly decompile/recompile all of them and mainly because it doesn't stop them from running fine with the rights dependencies.

Although here, this 7.0 regession in the retro-compatibility that was introduced in spring 6.1.12 is mainly breaking code by convention.
Leaving the code as is was wouldn't had any side effect in the codebase (we are talking of 2 string and a try catch), but you apparently chose to break retrocompatibility for the sake of purity.

Don't bother still, I will not try to argue over it and stick our code on the 6.2 version. I'm too tired for this and already had my share of argument on this exact same kind of issue again and again and again... As one say, hell is paved with good intentions, and coding is one hell of groundhog day.

Regards

[jhoeller]

@YSavanier no need to get frustrated and jump to conclusions (not blaming you for such feelings on a Friday night in any case). We are always willing to reconsider, we'd just like to understand the use case.

Precompiled libraries can be a burden indeed. A key question is: Will there be a chance to migrate those libraries in the near future, or will they stay in the javax namespace forever? So I understand that it's still not even on the horizon in your environment yet?

As for the single try-catch block, that's not quite the entire story for JSR-250 and JSR-330 support. We not only got @ManagedBean and @Named, we also got @Inject, @Qualifier, @Resource, @PostConstruct and @PreDestroy to consider - plus the corresponding support in spring-context-indexer and Spring AOT, plus tests. We could narrow it to partial support but it's hard to draw the line.

As for your specific ask, @ManagedBean is not commonly seen out there, and neither is @Named for the purpose of component scanning. I personally added those 20 years ago not because of common demand or commonality in the programming model, but just for completeness against vague assumptions on how non-Spring-dependent code could want to be detected. Over the years, it turned out that Java EE itself did not adopt them for those purposes and dropped @ManagedBean completely in the meantime.

So to clarify: You rely on Spring-driven component scanning to find @ManagedBean and @Named classes but you do not use dependency injection via @Inject or @Resource, or annotated init/destroy methods via @PostConstruct and @PreDestroy (in the javax namespace). Also, you are happy to upgrade everything else to Jakarta EE 11 level, with isolated use of certain precompiled libraries that happen to rely on @javax.annotation.ManagedBean and @javax.inject.Named but have no other javax dependencies.

For a path forward: Note that you could configure a custom include filter on your component-scan instruction, pointing to javax.annotation.ManagedBean and javax.inject.Named as additional types to detect. Granted, AnnotationBeanNameGenerator is also something to customize in addition. And if any such component scans are triggered from inside those precompiled libraries, then the only solution is indeed for us to reinstate support for those annotations out of the box.

Last but not least, I appreciate your early upgrade attempt to Spring Framework 7.0 - that is not the norm, in particular in a system with a lot of legacy. FWIW I'm surprised that this is the only thing holding you back.

[sbrannen]

For a path forward: Note that you could configure a custom include filter on your component-scan instruction, pointing to javax.annotation.ManagedBean and javax.inject.Named as additional types to detect.

To achieve that, you could configure component scanning similar to the following.

@ComponentScan(
	basePackages = "org.example",
	includeFilters = @Filter({
		javax.inject.Named.class,
		javax.annotation.ManagedBean.class
	})
)

Granted, AnnotationBeanNameGenerator is also something to customize in addition.

To achieve that, you would need to override AnnotationBeanNameGenerator.isStereotypeWithNameValue(...) to add support for javax.annotation.ManagedBean and javax.inject.Named, similar to what was done in commit e1826d2.

[sbrannen]

Please note that I have documented the recommendations in my previous comment in the reference manual.

[jhoeller]

Closing this issue for the time being, under the assumption that component scan customizations can still be used for the detection of javax based stereotypes.

Note that you may also bypass component scanning completely, declaring all necessary beans explicitly via @Bean methods instead, or even just listing the affected component classes via @Import on a configuration class. After all, component scanning is just a shortcut for not having to enumerate those classes. If the target classes are not detected by a default scan anymore, you may choose to explicitly declare them instead, avoiding any stereotype conventions to begin with.