Adding the websocket:decorator-factories element to a websocket:message-broker configuration in XML will prevent the associated SubProtocolWebSocketHandler from starting. Any attempts to make websocket connections will hang on the CONNECT frame.
Connect log with websocket:decorator-factories in place:
The "No Session for Generic Message" log is produced when using websocket:decorator-factories because the SubProtocolWebSocketHandler was not started when the CONNECT frame was received, and did not create a new session.
In Debugging, there actually was a SubProtocolWebSocketHandler which was started by the SmartLifecycle, but it was a different instance than the one wrapped by the decorator factory configured through websocket:decorator-factories.
Manually starting the SubProtocolWebSocketHandler from my DecoratorFactory as a workaround makes the connections usable, and the websockets function as expected.
It would seem that a separate instance is provided to the DecoratingFactoryBean by MessageBrokerBeanDefinitionParser, and this instance is never started.
I can see two instances created when websocket:decorator-factory is used in unit tests. What I'm not sure is whether we broke this recently or if it was always an issue? Looking at the code it looks more like this was always in issue. Was it working for you in any version since 4.1.2 (i.e. since 97596f).
I've only been using websockets since 4.2 (I've need for the new WebSocketStompClient), but I just switched my server project to Spring version 4.1.2.RELEASE to retest. I'm still able to reproduce the issue as described above.
In spring-websocket-4.2.0.BUILD-20150702.201539-518 everything works as expected. The SubProtocolWebSocketHandler instance that is started by the lifecycle is the same instance that's wrapped by the decorator, and websocket connections are made successfully. Thank you!