springwebsocketsockjs

Spring Websocket and 404 status on connection

In a working Spring MVC 4.0.2 project running under Tomcat 7.0.50, I'm trying to implement Spring Websocket with simple broker and sockjs stomp endpoint, following the official reference. So, in the contextConfigLocation (DistpacherServlet property) I've add a value "websocket-config.xml" which contains:

>     <websocket:message-broker application-destination-prefix="/app" >
>           <websocket:stomp-endpoint path="/monitor">
>             <websocket:sockjs />
>           </websocket:stomp-endpoint>
>           <websocket:simple-broker prefix="/topic"/>
>     </websocket:message-broker>

In eclipse console (catalina log) when I start Tomcat, appear the rows

  • Initializing ExecutorService 'clientInboundChannelExecutor'
  • Initializing ExecutorService 'clientOutboundChannelExecutor'
  • Initializing ExecutorService 'messageBrokerSockJsScheduler'
  • Mapped URL path [/monitor/**] onto handler of type [class org.springframework.web.socket.sockjs.support.SockJsHttpRequestHandler]

In the jsp page I put the code

. . . .
var socket = new SockJS("monitor");
var stompClient = Stomp.over(socket); . . . .

Unfortunately when I load the jsp page from Chrome (v32), I get this error:

Failed to load resource: the server responded with a status of 404 (Not Found)

http ://localhost:8080/(ProjectName)/monitor/info

Obviously I'm doing this test locally, then all other webapp resources are reachable at http ://localhost/(ProjectName) correctly.

What's wrong?

**** Update 20 Feb 2014 I've tried to follow this resolved stack question, which suggests to use Tomcat8 for Spring Websocket, unfortunately it doesn't work

Solution

  • Any log output on the server side as a result of the request to /monitor/info? How is the DispatcherServlet itself mapped? I would expect to "/" from what you have above.

    The SockJS endpoint is basically a URL mapped in Spring MVC (with a SimpleUrlHandlerMapping) so try other Spring MVC mapped controller methods. And turn up logging, could there be a filter or something else returning the 404?