Estaba echando un vistazo a WebSockets la semana pasada e hice algunas reflexiones sobre cómo implementar el lado del servidor con Java Servlet API. No paso mucho tiempo, pero se encontró con los siguientes problemas durante unas pruebas con Tomcat, que parecen imposibles de resolver sin un parche en el recipiente o al menos hacer modificaciones específicas de contenedores a la aplicación HttpServletResponse:WebSockets atendidos por un Servlet Container
La especificación WebSocket ordena un mensaje definido en la respuesta HTTP 101. HttpServletResponse.setStatus (código int, mensaje de cadena) está en desuso sin mencionar un reemplazo utilizable. Después de cambiar la configuración predeterminada de Tomcat, hice que Tomcat respetara mi cadena de mensajes, pero como el método está en desuso, no estoy seguro de si esto funcionará con otros contenedores de servlets.
La especificación WebSocket requiere un orden específico de los primeros encabezados en la respuesta HTTP a la solicitud de actualización de la conexión. La API de servlet no ofrece un método para especificar el orden de los encabezados de respuesta y Tomcat agrega sus propios encabezados a la respuesta, colocando algunos de ellos antes de los encabezados, que se agregan mediante la implementación de servlet.
Como la longitud del contenido de la respuesta no se conoce al confirmar el encabezado, Tomcat cambia automáticamente a codificación de transferencia fragmentada para la respuesta, que es incompatible con la especificación WebSocket.
Me estoy perdiendo algo obvio, o es realmente no es posible integrar los puntos finales de servidor WebSocket en una aplicación web basada servlet?
Me encontré con casi los mismos problemas. Realmente quería extender Tomcat, para mostrar cómo me gustaría que fuera un "Servidor WebSocket", cuando se agrega a las especificaciones Java EE. Para ver cómo hackeé Tomcat, puede consultar los parches en http://java.dzone.com/articles/tomcat-websockets-html5 –