Use JDK ObjectInputFilter instead of calling AllowedListDeserializingMessageConverter::checkAllowedList in ConfigurableObjectInputStream::resolveClass

[quaff]

I think it's better to use standard API.
see Java Serialization Filters

spring-amqp/spring-amqp/src/main/java/org/springframework/amqp/support/converter/SimpleMessageConverter.java

Lines 158 to 162 in 603e6c8

	protected Class<?> resolveClass(ObjectStreamClass classDesc) throws IOException, ClassNotFoundException {
	Class<?> clazz = super.resolveClass(classDesc);
	checkAllowedList(clazz);
	return clazz;
	}

spring-amqp/spring-amqp/src/main/java/org/springframework/amqp/support/converter/SerializerMessageConverter.java

Lines 167 to 172 in 603e6c8

	protected Class<?> resolveClass(ObjectStreamClass classDesc)
	throws IOException, ClassNotFoundException {
	Class<?> clazz = super.resolveClass(classDesc);
	checkAllowedList(clazz);
	return clazz;
	}

[artembilan]

Well, the ConfigurableObjectInputStream is still going to be there since it relies on the specific ClassLoader:

/**
 * Special {@link ObjectInputStream} subclass that resolves class names
 * against a specific {@link ClassLoader}.
 *
 * @author Juergen Hoeller
 * @since 2.5.5
 * @see org.springframework.core.serializer.DefaultDeserializer
 */
public class ConfigurableObjectInputStream extends ObjectInputStream {

Please, revise your request about the logic we do in the AllowedListDeserializingMessageConverter to use that ObjectInputFilter instead of resolveClass() override.
Otherwise this is confusing and might be closed without the fix.

Thanks

[artembilan]

I made the change: artembilan@16c9e8f.

But decided that it is a bit of breaking in the behavior since now we do not throw SecurityException directly, but though some stack trace dictated by the ObjectInputFilter with its InvalidClassException (which is a checked IOException).

So, pushing this to the future when we start a new major version.