ClassPathScanningCandidateComponentProvider doesn't respect AnnotationTypeFilter [SPR-12802]

[spring-projects-issues]

Diego Plentz opened SPR-12802 and commented

ClassPathScanningCandidateComponentProvider doesn't find interfaces when used with AnnotationTypeFilter. AnnotationTypeFilter has a constructor that explicitly says that it can be used to find annotated interfaces:

public AnnotationTypeFilter(Class<? extends Annotation> annotationType,
boolean considerMetaAnnotations,
boolean considerInterfaces)
Create a new AnnotationTypeFilter for the given annotation type.
Parameters:
annotationType - the annotation type to match
considerMetaAnnotations - whether to also match on meta-annotations
considerInterfaces - whether to also match interfaces

But, since ClassPathScanningCandidateComponentProvider implementation filter interfaces out in the isCandidateComponent(AnnotatedBeanDefinition beanDefinition) method, the type filter doesn't work as expected.

ClassPathScanningCandidateComponentProvider provider = new ClassPathScanningCandidateComponentProvider();
provider.addIncludeFilter(new AnnotationTypeFilter(MyCustomAnnotation.class, false, true));
Set<BeanDefinition> findCandidateComponents = provider.findCandidateComponents("com.foo");

---

Affects: 4.1.5

Issue Links:

• Introduce a mechanism for abstract types at component scanning [SPR-11663] #16286 Introduce a mechanism for abstract types at component scanning

[spring-projects-issues]

Juergen Hoeller commented

At this point, that mechanism works as designed: Our component scanning can only register concrete component classes with an application context, since the bean factory would not know what to do with them otherwise. What would you expect to happen to registered interfaces in your scenario?

Currently, specified type filters are allowed to select based on simple criteria, with non-concrete classes automatically filtered out still. So we can't simply refine that check in existing branches of the framework, otherwise some existing type filter configurations might break.

That said, we are considering a revision of the component scanning contract to allow for registering abstract component types, including interfaces, in combination with a mechanism which allows for transforming such components to usable bean classes: see #16286.

Juergen

[spring-projects-issues]

Diego Plentz commented

Juergen,

I understand that this behaviour is the one expected when registering interfaces for Spring context, but this class is being used by users(me included - and you can quickly find a lot of others users in a quick google search) to scan the classpath, since it's a better dependency to have then https://code.google.com/p/reflections/, if you're already using spring in your project.

The onde thing that isn't really clear to me is why that AnnotationTypeFilter's constructor exists since ClassPathScanningCandidateComponentProvider always remove the non-concrete interfaces anyway.

[joeltoby]

I agree that the current behaviour of ignoring AnnotationTypeFilters is not intuitive or helpful since developers are using ClassPathScanningCandidateComponentProvider exactly as Diego Plentz outlined.

Is there now (several years later) any better way to filter ClassPathScanning by annotations? If not, would you consider reopening this please @jhoeller ?

[sinogermany]

@joeltoby and whoever is looking for a temp solution before #16286 gets merged:

ClassPathScanningCandidateComponentProvider provider = new ClassPathScanningCandidateComponentProvider(false) {
    @Override
    protected boolean isCandidateComponent(AnnotatedBeanDefinition beanDefinition) {
        return super.isCandidateComponent(beanDefinition) || beanDefinition.getMetadata().isAbstract();
    }
};

[joeltoby]

Thank you @sinogermany. I'll give that a try!