Inbound bridge participant deserialiser is registered when InboundBridgeManager is created . That deserialiser is immediately used to recreate participants and update REST-AT coordinator via its HTTP resource.
In WildFly deserialiser registration used to be triggered by creating InboundBridgeManager instance in InboundBridgeService#start method.
However, Undertow subsystem update was introduced which collected and held all HTTP requests until application server completed boot-up. This caused a lock because HTTP call to REST-AT coordinator was being held and InboundBridgeService was waiting for the response. As a result server never completed boot.
Tom has removed that initialisation as a workaround . Everything still works, because inbound bridge recovery manager initialises InboundBridgeManager too. However, only in the second pass. This causes warnings messages during the first cycle of the recovery by REST-AT recovery module.
I'm suggesting to remove deserialiser registration from InboundBridgeManager constructor to keep it as simple as possible and move it to other place were it could be invoked safely and on time e.g. start of first pass of InboundBridgeRecoveryModule.