Spring destroy-method not called on improperly wired prototype

If a prototype bean is not properly wired, spring will still create it on demand (without erroring, even at TRACE level) but will not call the destroy-method if one is specified. I've verified this on spring version 4.3.22.RELEASE and 5.1.6.RELEASE (using both CommonsPoolTargetSource and CommonsPool2TargetSource) on several 1.8 JDKs.

Consider the following class:

public class Thing {
  public Thing() {
    System.out.println("A thing was created");
  }
  public void close() {
    System.out.println("A thing was destroyed");
  }
}

And the following xml configuration:

<bean id="pool" class="org.springframework.aop.target.CommonsPoolTargetSource">
    <property name="targetBeanName" value="thing" />
    <property name="minIdle" value="1" />
    <property name="timeBetweenEvictionRunsMillis" value="3000" />
    <property name="minEvictableIdleTimeMillis" value="3000" />
</bean>
<bean id="thing" class="Thing" scope="prototype" destroy-method="close">
</bean>

While the application runs, we can see Things properly being created and destroyed over and over in the console, as we would expect:

A thing was created
A thing was destroyed
A thing was created
A thing was destroyed

Now lets change bean thing to have an invalid definition:

<bean id="thing" class="Thing" scope="prototype" destroy-method="close">
        <property name="madeUpProperty" ref="someOtherValidBean" />
</bean>

Spring still manages to successfully create the bean thing. However, the destroy-method is no longer called; Things are constantly created, but never cleaned up. Additionally, no warnings or errors are logged from spring - even at TRACE level. I would expect either the destroy-method to still be called, or some sort of warning/error from spring.

Comment From: quaff

Prototype beans are created but not managed by IoC container, destroy-method is ignored. https://stackoverflow.com/questions/50681027/do-spring-prototype-beans-need-to-be-destroyed-manually

Comment From: snicoll

Thanks @quaff

@jayeeebee I don't know what's closing a Thing with prototype scope, and I can't just trust a piece of log. If you want to make a case of a faulty behaviour we should have at least a way to reproduce the problem ourselves.

The reference documentation states:

In contrast to the other scopes, Spring does not manage the complete lifecycle of a prototype bean. The container instantiates, configures, and otherwise assembles a prototype object and hands it to the client, with no further record of that prototype instance. Thus, although initialization lifecycle callback methods are called on all objects regardless of scope, in the case of prototypes, configured destruction lifecycle callbacks are not called. The client code must clean up prototype-scoped objects and release expensive resources that the prototype beans hold.