On 29/10/2013 13:01, Niki Dokovski wrote: > On Tue, Oct 29, 2013 at 2:51 PM, Mark Thomas <ma...@apache.org> wrote: > >> On 29/10/2013 12:41, Niki Dokovski wrote: >> >>> WebSocket container can be used in Java SE env only but for a standard >> JSR >>> 356 compliance implementation an existing servlet container is needed. >> >> No it is not. >> >>> Basically you are correct if you don't refer to JSR 356. But my question >>> was related to improving the spec, triggered by Romain's question. >> >> Wrong again. >> >> You can implement a specification compliant JSR 356 server container >> without implementing any other J2EE specs. This was an explicit design >> decision made by the JSR 356 EG and explains, for example, why the >> HttpSession instance is passed as Object rather than as >> javax.servlet.http.HttpSession. >> >> I still do not see where, how or why there is a specification issue here. >> > > The simple fact that you cannot pass the TCK, hence claim compatibility > proves the other way.
If the TCK requires that the WebSocket implementation be part of a J2EE container then that is an issue with the TCK. I only had access to a draft of the TCK and there were much more fundamental issues with it at that stage. The intention of the WebSocket EG was that a specification compliant WebSocket server container could be implemented on a stand-along basis without having to implement any other J2EE specs. I don't believe there is anything in the WebSocket spec that contradicts that. For example, see section 6.3 which explicitly references implementations that do not include a Servlet container. > The dependency is more hidden to me. Mark, I > understand your point by saying ok when implementing the websocket > container I don't use servlet spec APIs. The javax.servlet APIs are not > used in the implementation, are they? In Tomcat's implementation, yes they are because that was how I opted to implement it. My intention was to produce a container neutral WebSocket implementation. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
