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