JSR-330 support for component detection is inconsistent [SPR-6465]

[spring-projects-issues]

Eberhard Wolff opened SPR-6465 and commented

If I annotate a class using @Named it is instantiated by context:component-scan . However, @Named is just an example for an @Qualifier annotated Annotation. The JavaDoc for @Qualifier states that the specification only covers using such annotations on fields and methods, classes are optional. So even though this behavior does not contradict the specification it is not required either.

But if @Named means that a class is implemented by context:component-scan the same should work for my own @Qualifier annotated Annotation as well. That is not the case.

Also a class annotated with @Singleton is not instantiated by context:component-scan and probably other Annotations that are marked with @Scope work the same way. I think it would be more logical to have these annotations work with context:component-scan than the @Named annotation as they clearly belong to implementation classes which @Named does not. But again this is not covered by the spec.

---

Affects: 3.0 RC2

1 votes, 3 watchers

[spring-projects-issues]

Juergen Hoeller commented

The problem here is that scope annotations are not consistently used in JSR-330: The default prototype scope does not have a corresponding annotation by design. So for that kind of component, we can't rely on a scope annotation for detection purposes. In addition to that inconsistency, we are not detecting Spring-style components based on scope annotations either. We'd have to do both or none.

Admittedly, we are applying a special meaning to JSR-330's @Named here: When doing component scanning, @Named is more than just a qualifier annotation - it's suddenly a kind of stereotype then, suggesting a name value analogous to Spring's own @Component. This is of course not covered in the JSR-330 spec at all but rather our best effort try to find a JSR-330 equivalent of @Component.

Our recommendation is to use Spring-style stereotypes anyway and just add JSR-330 injection and qualifier annotations for the injection points. The same applies to scoping: We recommend Spring-style scoping over JSR-330 scoping, in particular with respect to the default singleton scope in Spring that differs from the default prototype scope in JSR-330.

Juergen

[spring-projects-issues]

Eberhard Wolff commented

Jürgen, I see your point. I guess my main problem is that I am surprised that a class that is annotated with @Singleton is not detected - even though that is an JSR 330 official class level annotation that makes it quite apparent this would be a bean. So I would argue @Singleton annotated classes should become Spring beans. Not sure whether there is any general solution to this issue.

[spring-projects-issues]

Alexandre Navarro commented

Juergen, I'm not sure I understand what you said.
@Named before a class is equivalent @Component with scope singleton but it is not in the jsr 330 spec, you add this feature to have an equivalent @Component.

[spring-projects-issues]

Alexandre Navarro commented

I confirmed the bug, instantion of a class works well with @Named or @Component but not with @Singleton.

[spring-projects-issues]

Juergen Hoeller commented

Some related news: Java EE 6 went final a couple of days ago. It includes a "javax.annotation.ManagedBean" annotation now, which is exactly what we need for our purposes here: It is defined as supporting @PostConstruct and @PreDestroy and also @Resource injection, and hinting at supporting other means of injection too (such as JSR-330's @Inject).

So as of Spring 3.0 GA (scheduled for tomorrow), we support @ManagedBean as well - as alternative to @Component and @Named - when present on the classpath. This should be fully compliant with the intentions of @ManagedBean and provide some portability between Spring component management and Java EE 6 component management. (Although that's more about know-how than about practical portability...)

However, "javax.annotation.ManagedBean" is a bit hard to obtain, since it is part of JSR-250 v1.1 but actually defined in a separate "Managed Beans 1.0" specification which is part of JSR-316 (the Java EE 6 umbrella JSR). The annotation type is available on the classpath of a Java EE 6 server, in any case; let's see whether it'll be available as a standalone jar as well (before Java SE 7, that is).

So conceptually, I'd recommend using @ManagedBean as a stereotype if you'd like to remain standards compliant. If that class isn't available to you (as per the discussion above), @Named is as close as it gets as a direct alternative. I'd rather go the Spring @Component way then, though, simply accepting that Spring stereotype annotation for the time being.

At this point, detecting components based on the plain presence of a scope annotation isn't being considered for Spring 3.0.x anymore. Note that neither JSR-330 nor any other Java EE 6 JSR covers detection based on scope annotations either; it would be just as custom as our use of @Named. We might revisit this in Spring 3.1, when considering JSR-299's @NormalScope facility as well.

Juergen

[spring-projects-issues]

Alexandre Navarro commented

I asked the upload javax.annotation-1.1 in the maven repository jar of https://glassfish.dev.java.net/issues/show_bug.cgi?id=11309.

Thanks if you are interested to vote for it.

[spring-projects-issues]

Alexandre Navarro commented

Just for information, the jar with @ManagedBean is available on glassfish maven repository http://download.java.net/maven/glassfish

<dependency>
<groupId>org.glassfish</groupId>
<artifactId>javax.annotation</artifactId>
<version>3.0</version>
</dependency>

(weird to have a glassfish in groupId).

Alexandre

[spring-projects-issues]

Alexandre Navarro commented

@ManagedBean works well (also with @Scope("prototype")) but @Singleton does not work.

[spring-projects-issues]

Eric Sirianni commented

There is also a friendlier (i.e. Apache) licensed implementation of the Java EE6 annotations available from geronimo.

http://svn.apache.org/viewvc/geronimo/specs/trunk/geronimo-annotation_1.1_spec/

https://issues.apache.org/jira/browse/GERONIMO-5017