ProxyFactoryBean declaration may lead to unexpected non-fatal "FactoryBean threw exception from getObjectType" stacktrace output

[smurf667]

Affects: Spring Boot 3.1.4 / Spring 6.0.12

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

1. An ApplicationContextInitializer is configured
2. The initializer adds a BeanFactoryPostProcessor
3. The processor defines a proxied service
4. 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 using a distilled version started from Spring Initializr is shown here: https://github.com/smurf667/test-spring-boot3-aop-issue

This was asked on Stackoverflow, and some helpful feedback was already given (including the recommendation to open an issue to get this behavior checked):

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.

Is there a problem with the way we use Spring, should the stacktrace be logged with a more lenient level (lower than INFO), or is this potentially a bug?

Thanks!