StompSubProtocolHandler eventPublisher being cleared by SubProtocolWebSocketHandler [SPR-11825]

[spring-projects-issues]

Jeffrey Barrus opened SPR-11825 and commented

I am trying to subscribe to SessionConnectEvent but found that it is never published. After stepping through code, I found that the StompSubProtocolHandler ends up with null for eventPublisher after context initialization. It looks like when SubProtoocolWebSocketHandler is initialized, setProtocolHandlers is called before setApplicationEventPublisher. This results in the StompSubProtocolHandler getting its eventPublisher set to null.

See line 137 in SubProtocolWebSocketHandler.java

if (handler instanceof ApplicationEventPublisherAware) {
     ((ApplicationEventPublisherAware) handler).setApplicationEventPublisher(this.eventPublisher);
}

---

Affects: 4.0.5

Referenced from: commits e9ecaf6, 0dddb6f

[spring-projects-issues]

Rossen Stoyanchev commented

The code referenced on line 137 should work. Can you describe your setup in more detail?

[spring-projects-issues]

Rossen Stoyanchev commented

Have you tried setting some breakpoints on startup around line to get some insight about what happens?

[spring-projects-issues]

Jeffrey Barrus commented

Sure, here's my XML setup:

<websocket:message-broker>
    <websocket:stomp-endpoint path="/messaging">
        <websocket:sockjs/>
    </websocket:stomp-endpoint>
    <websocket:simple-broker prefix="/topic"/>
</websocket:message-broker>

During initialization a breakpoint at line 138 of StompSubProtocolHandler gets this 3 times:

• From ApplicationContextAwareProcessor with an instance of XmlWebApplicationContext
• From ApplicationContextAwareProcessor with an instance of XmlWebApplicationContext (not sure exactly why it is called twice...)
• From SubProtocolWebSocketHandler with null

Breakpoints in SubProtocolWebSocketHandler line 194 (setter), line 138 (setApplicationEventPublisher in StompHandler)

• 138 gets hit first (setting the StompSubProtocolHander eventPublisher to null)
• 194 gets hit second

Why is the SubProtocolWebSocketHandler trying to set the event publisher on the StompSubProtocolHandler anyway?

Do you need more information?

[spring-projects-issues]

Jeffrey Barrus commented

I stepped through the spring-websocket-portfolio application and it looks like this is not an issue in it. The Stomp sub handler is not added during bean property setup, but added much later in the WebSocketConfig class which calls into WebMvcStompEndpointRegistry.addEndpoint and sets the stomp handler on line 96. It looks like that class creates an instance of StompSubProtocolHandler directly, rather than as a bean (is there a reason for that?).

The issue is probably related to using XML configuration.

[spring-projects-issues]

Rossen Stoyanchev commented

During initialization a breakpoint at line 138 of StompSubProtocolHandler gets this 3 times

Line 138 from the source code snippet in the original comment I believe is from SubProtocolWebSocketHandler, not StompSubProtocolHandler. I think you mean line 168 of StompSubPH, i.e. the setApplicationEventPublisher method. At any rate it looks like an initialization issue that for some reason didn't affect the Java config as it does the XML namespace.

Why is the SubProtocolWebSocketHandler trying to set the event publisher on the StompSubProtocolHandler anyway?

Because we can't be sure that StompSubPH is a Spring bean.

[spring-projects-issues]

Jeffrey Barrus commented

Thanks for your help. Not trying to be critical, just asking to understand.

This is a great feature, thanks for your work.

[spring-projects-issues]

Rossen Stoyanchev commented

No worries. It is a real bug and your report is very helpful.

[spring-projects-issues]

Artem Bilan commented

The same issue: http://stackoverflow.com/questions/23903419/spring-websocket-sessiondisconnectevent

[spring-projects-issues]

Artem Bilan commented

PR: #548

[spring-projects-issues]

Rossen Stoyanchev commented

Re-open to make sure it's backported to 4.0.6.