Spring Introduce a mechanism for abstract types at component scanning [SPR-11663]

cemo koc opened SPR-11663 and commented

I would like to create some proxy beans based on interfaces. I will provide some basic examples to make clear.

Use case 1: Creating a proxy restful client based on interface

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Component
public @interface Restful {
   String value() default "";
}

@Restful 
public interface MyRestClient {

  @Get("/events/{year}/{location}")
  EventList getEventsByYearAndLocation(int year, String location);

 }

Use case 2: Creating a proxy repository instance based on interfaces

@MyRepository // new annotation
public interface PersonRepository {
   List<Person> findByLastnameOrderByFirstnameAsc(String lastname);
  List<Person> findByLastnameOrderByFirstnameDesc(String lastname);
}

In order to provide this functionality I had to dig many codes from Spring Data project and became little frustrated with result. I had to create 6-7 class and most of them are duplicated. As a result of my implementation basically I had to create a custom InstantiationAwareBeanPostProcessorAdapter to create beans with custom logic after registering them.

I would like to see a configuration mechanism for registering beans for abstract types dynamically. I was considering an API for component scanning such as ComponentScanProcessor. Each registered ComponentScanProcessor can decide about candidates.

This will help to reduce a fair amount codes in many projects even Spring Data which is creating repository beans from Interfaces.

Affects: 4.0.3

Issue Links: - #17399 ClassPathScanningCandidateComponentProvider doesn't respect AnnotationTypeFilter - #18794 @Configuration interface with Java 8 default methods (as a standalone artifact) - #16509 Spring-specific index file for component candidate classes - #19118 Classes with abstract @Lookup methods not registered in case of classpath scanning

3 votes, 6 watchers