How to avoid a Spring 6 non-fatal "TargetSource cannot determine target class" stacktrace output?

We have a Spring application that defines some beans using a BeanFactoryPostProcessor. Using Spring 6 (Spring Boot 3), a non-fatal INFO level stacktrace is printed at startup like this:

2023-10-19T16:15:42.223+02:00  INFO 18756 --- [           main] o.s.b.f.s.DefaultListableBeanFactory     : FactoryBean threw exception from getObjectType, despite the contract saying that it should return null if the type of its object cannot be determined yet

org.springframework.aop.framework.AopConfigException: TargetSource cannot determine target class: Either an interface or a target is required for proxy creation.
        at org.springframework.aop.framework.DefaultAopProxyFactory.createAopProxy(DefaultAopProxyFactory.java:65) ~[spring-aop-6.0.12.jar:6.0.12]
...

The same code works fine (without the stacktrace being output) in Spring 5 (Spring Boot 2). What the application does is basically

An ApplicationContextInitializer is configured
The initializer adds a BeanFactoryPostProcessor
The processor defines a proxied service
The service is used; in Spring 5 no errors are shown, in Spring 6 the stacktrace appears - the application works in both cases

A small demonstration of the issue is shown here: https://github.com/smurf667/test-spring-boot3-aop-issue

Are we doing something wrong, or is this an issue/regression in Spring 6?

Solution

This is not a definitive answer, but too much info to comment.

I debugged in both Spring Boot versions, and what I found out is that the exception is caught and logged here.

The difference between Spring 5.3.29 (Boot 2.7.15) and Spring 6.0.12 (Boot 3.1.4) is that field AdvisedSupport.targetSource is set earlier in the old Spring version than in the new one, i.e. when the target source is checked in method DefaultAopProxyFactory.createAopProxy, it is already set in the old Spring version, but still an EmptyTargetSource instance in the new version, causing the exception to be thrown. Funny detail: The error log says that throwing an exception there violates a contract, which is why it is caught and logged.

I think, this is worth creating a Spring issue, asking for clarification if this is considered to be a bug, merely an annoyance or the problem sits in front of the computer, somehow using those context initialiser and bean factory post processors in a wrong or non-canonical way. I am not a Spring user at all and have zero knowledge about that stuff. I am interested in this question merely, because I am kind of an AOP expert. I also have no idea what your real factory is actually supposed to do. If you would just annotate and auto-wire your components canonically, at least in this example you would not need that functionality at all. I guess, your real situation is more complex than your minimal reproducer shows.

That the application works in both cases, is probably to be expected, because DefaultAopProxyFactory.createAopProxy for the same factory is called again later after the target source has been set already, the second and subsequent times not causing any exceptions anymore.

Update: Spring issue #31473, createy by @JanDasWiesel according to my recommmendation, was resolved and the fix scheduled to be part of the upcoming Spring 6.0.14 release.