Manually setting up Spring WebSocket STOMP support

I'm trying to set up a STOMP WS endpoint using spring-websocket and spring-messaging. I am trying to do this manually: no application context is involved at all, and certainly no dispatcher. My goal is to wire up the appropriate Spring components in code inside a ServletContextListener, then register the wired up components directly with the javax.websocket.server.ServerContainer in my JSR 356 compatible container (Tomcat 7). At first, I would like to get this working with the "simple" broker built into spring-messaging; secondly, I would like to implement my own "broker" to directly integrate with an in-process ActiveMQ using the VM transport. This would be in contrast to the STOMP relay which spring-messaging also provides.

The Spring documentation states (http://docs.spring.io/spring/docs/current/spring-framework-reference/html/websocket.html):

"...Spring’s WebSocket support does not depend on Spring MVC. It is relatively simple to integrate a WebSocketHandler into other HTTP serving environments with the help of WebSocketHttpRequestHandler."

However, I am not finding it to be simple. Essentially, I started with:

public void contextInitialized(ServletContextEvent sce) {
    ServerContainer websocketContainer = (ServerContainer) sce.getServletContext().getAttribute("javax.websocket.server.ServerContainer");
    ???
    websocketContainer.addEndpoint(???);
}

And ended up with an incoherent mess of assorted spring-websocket and spring-messaging constructor invocations which do not compile and are certainly not worth reproducing here.

I realize this is a bit vague, this is because I'm a bit lost! Has anyone done something like this, or has some general guidance to contribute?

Solution

Did you try sample application - tests for the stock portfolio. (This link is at the very end of the spring documentation link).

It says

Demonstrates 3 approaches to testing a Spring STOMP over WebSocket application:

Server-side controller tests that load the actual Spring configuration (context sub-package)
Server-side controller tests that test one controller at a time without loading any Spring configuration (standalone sub-package)
End-to-end, full integration tests using an embedded Tomcat and a simple STOMP Java client (tomcat sub-package) See the Javadoc of the respective tests for more details.

Second option is probably what you need.