Spring Error running spring native executable, error: A component required a bean of type 'com.example.MyInterface' that could not be found.

The project is built with command mvnw native:compile -Pnative. The command builds the executable successfully. However, it fails to start the application.

The MyInterface is configured using a class annotated with @Configuration, with method returning ServiceLocatorFactoryBean. Here is an example code of the method:

@Bean
public ServiceLocatorFactoryBean myInterfaceBean() {
    ServiceLocatorFactoryBean slfb = new ServiceLocatorFactoryBean();
    slfb.setServiceLocatorInterface(MyInterface.class);
    return slfb;
}

Does Spring Native supports such bean? If not, what is the alternative? Thanks.

Another reference to the issue on Stackoverflow that are very similar: https://stackoverflow.com/questions/75881796/spring-boot-3-service-locator-interface-in-the-servicelocatorfactorybean-could-n

Comment From: snicoll

This is documented in the best practices for AOT.

There's nothing we can do based on the construct above as you're not providing the signature of the bean to expose so we can't optimize it at build-time. I am wondering why you'd need to have this flexiblity with javaconfig. Given your @Bean method can call any regular code, that looks a bit overkill. Can you share why you're using such construct?

Comment From: KaeYan93

Hi @snicoll , thanks for the prompt reply.

There's nothing we can do based on the construct above as you're not providing the signature of the bean to expose

Signature means the implementation class type?

Can you share why you're using such construct?

I cannot give the answer as I havent understand the considerations from previous developers. Can i understand how can this construct be supported? The MyInterface is actually a ServiceFactory (It is an interface) which has some methods to provide service instance. I guess it was intended to use the service locator pattern to provide a consolidated instances of services.

Comment From: snicoll

How about something like

``` @Bean public MyService myInterfaceBean(MyInterface myInterface) { return myInterface.getService(); } ````

The bottom line is that the bean type must be exposed if you want to be able to inject it elsewhere. It's not only a problem with Spring BTW, doing this means that GraalVM cannot infer what the target type is going to be and can't apply proper optimizations.

Comment From: KaeYan93

Hi @snicoll , for my usecase, i am using ServiceLocatorFactoryBean with the ServiceFactory interface, which contains methods to get service (interface) based on name. Then, we have classes that implements the service interface with the name after the @Component argument, so that the Spring framework returns the correct service impl based on name, when the method is called. This is done because we have multiple type of services, and each service has different impl based on different protocol.

So, if i using spring native, i cannot leverage this feature anymore?

Comment From: snicoll

So, if i using spring native, i cannot leverage this feature anymore?

I think I've tried to make that clear already. This kind of runtime flexibility is not compatible with optimizing the context at build-time. I am not sure what ServiceLocatorFactoryBean buys you in a Javaconfig world to be honest. This was designed for the XML world when we couldn't as easily configure such arrangement. If you are interested in running your application as a native image, non-deterministic flexibility like this could also mean longer build times and bigger images. Please take the time to review your configuration.