rabbit:connection-factory : understanding why a spring namespace element differs from the class it does wrap

I am puzzled about a difference between 2 uses cases I expected to be close enough to work the same way.
I have a Spring xml content within which I am defining a messaging bridge, using Spring Integration and spring-amqp to consume and publish from/to a rabbitMq broker.

The broker has to be accessed through SSL, where it used to be formerly accessed the non-TLS way.
We have no problem publishing to a rabbit on port 5671 (SSL). But we encountered one consuming... with the ConnectionFactory not using a SSL socket but a standard one... resulting in the server refusing the incoming frame because of an "{unsupported_record_type,65}".

After trying various changes, we ended up having it work, replacing a basic bean-based declaration by the corresponding "namespaced" element... ie :

"Bean" method, not Working:

<bean id="rabbitConnectionFactory" class="org.springframework.amqp.rabbit.connection.CachingConnectionFactory">
    <constructor-arg value="clientSSLConnectionFactory" />
    <property name="addresses" value="some.fully.qualified.name:5671" />
    <property name="username" value="user" />
    <property name="password" value="password" />
    <property name="cacheMode" value="CONNECTION" />
    <property name="connectionCacheSize" value="50" />
    <property name="virtualHost" value="/" />
</bean>

becomes

"Namespace" method : Working:

<rabbit:connection-factory id="rabbitConnectionFactory" 
		connection-factory="clientSSLConnectionFactory"
		addresses="some.fully.qualified.name:5671"
		username="user"
		password="password"
		cache-mode="CONNECTION" 
		connection-cache-size=50" 
		virtual-host="/" />

I though both were identical (and that the namespace was basicall a wrapper), but after setting up some breakpoints within ConnectionFactory and CachingConnectionFactory (mainly within constructors and new connection methods), I realized that there were not constructed the same way. Especially, we saw that, with the namespace method, the connexion was using a basic socket for the first method while a SSLSocket was used for the second one.

We tracked the connexion flow down to this very basic flow (below) : it shows which (main!) methods / classes participate in the set up of the SSL Socket, and later the connection.

You can see that the useSslProtocol method is called in both cases, but the "bean" method does use it only once, through a ConnectionFactory that is not the one used for the later connection... hence the non-SSl socket.
I added the #ID of the objects provided by Eclipse debugger (usefull here to show whether objects are the same instance or not)

Obviously, I could be satisfied with the namespace solution... but unfortunately it does not allow to setup "connectionListeners" (that we use).... and also I would like to understand a little deeper how do Spring and NamespaceHandlers do work.

I might be able to go further in my analysis, but I must also confess I am not easy enough with Spring... although I undersand most mecanisms, I experience some difficulties using this knownledge to figure out what is really going on on the "all magical" process of instanciation.
EG, I know the <object> namespace does use a <Object>NamespaceHandler ( https://docs.spring.io/spring-amqp/api/org/springframework/amqp/rabbit/config/RabbitNamespaceHandler.html), but I wasn't able to undersand how does this make the namespace differ from the basic bean.

So... any hint to help us achieve using the Bean method (or include the listners) and/or understand the difference is welcome here.

The NamespaceHandler only provides the needed information on with what class to parse certain tags. It will link connection-factory to a ConnectionFactoryParser which knows what to do with that specific element. It will register beans or BeanDefinition into the application context.

However there is one, quite big, difference between your bean and the namespace. In your bean definition you are using a constructor-arg with a value. This will lead to invoking the constructor that takes a String (which is the hostname, which you later override). What you intended was to use a ref to reference another bean in the context.

So basically your bean definition doesn't do anything with the clientSSLConnectionFactory bean, where as the one with the namespace does.