Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-issuemaster opened this issue Aug 1, 2016 · 6 comments

Comments

@spring-issuemaster
Copy link
Collaborator

commented Aug 1, 2016

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:

Issue Links:

  • #16286 Introduce a mechanism for abstract types at component scanning
@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 6, 2016

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 6, 2016

Manfred Quasten commented

Maven-Poject with JUnitTest

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 6, 2016

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 7, 2016

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 23, 2017

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 1, 2017

Manfred Quasten commented

Works in 4.3.6.

Thanks and Regards

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.