Classes with abstract @Lookup methods not registered in case of classpath scanning [SPR-14550]

[spring-projects-issues]

Manfred Quasten opened SPR-14550 and commented

@Service("exchangeRateService")
class ExchangeRateServiceImpl implements ExchangeRateService {
...

@Lookup
ExchangeRateCalculatorBuilder newBuilder() {
return null;
}

}

the newBuilder Method is used inside an other public method and it works fine.

But when I will make the service class and the method newBuilder abstract then an exception is thrown:
No qualifying bean of type [de.mq.portfolio.exchangerate.support.ExchangeRateService] found for dependency: expected at least 1 bean which qualifies as autowire candidate for this dependency.

Ok, I can understand, that the spring container will not instantiate abstract classes but when only methods for methodInjection are abstract the bean can be instantiated. It is enhanced by cglib or what ever and it works as I've tried without abtract. For the (cglib) proxy there is no difference if an abstract or an other method will be overwritten. It is not very esthetic to write the dummy method returning null or what ever and it is not nesseary. In case of an abstract class that has only abstract methods for method injection the container can instantite the proxy.

---

Affects: 4.2.5

Attachments:

• methodinjection.test.zip (7.89 kB)

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

As far as my tests go, such scenarios work fine: We generally support classes with abstract @Lookup methods, and we seem to consistently find them in regular injection scenarios.

Could you please submit a minimal use case that reproduces your specific scenario?

[spring-projects-issues]

Manfred Quasten commented

Maven-Poject with JUnitTest

[spring-projects-issues]

Manfred Quasten commented

I've attached a maven project with a JunitTest and a simple Senario. You are right spring will support abstract method scenarios. It will work, when the ServiceBean (ArtistService in my example project) is defined in XML ( application.xml in the example). The Test runs successfull. When you remove the ArtistService in application.xml and only the @Service Annotation will define the ArtistService bean, the test fails with no such bean. So I think in cases when the abstract Service class ist defined with @Service and not in xml abstract classes are not created by spring. When you remove the abstract at class and method level and return null in the newBuilder() method it works also with the @Service Bean-Definition. So I've found my workaround. I can define it in xml and when it is fixed I can remove the xml and use the @Service.
The @Lookup is a nice new feature, injecting FacesContext in Controllers for example ...

[spring-projects-issues]

Juergen Hoeller commented

This is actually a limitation in our classpath scanning algorithm: We generally do not register any non-concrete classes there. Explicit bean definitions, whether XML-based or through AnnotationConfigApplicationContext.register calls, do not suffer from that limitation and allow for such abstract classes.

[spring-projects-issues]

Juergen Hoeller commented

Since we're not going to introduce a general mechanism for abstract types in our component scanner, I've added a specific check for abstract classes with @Lookup methods to the isCandidateComponent algorithm. This is easy enough to backport to 4.3.6 as well.

[spring-projects-issues]

Manfred Quasten commented

Works in 4.3.6.

Thanks and Regards