On 29/10/2013 13:24, Niki Dokovski wrote: > On Tue, Oct 29, 2013 at 3:08 PM, Mark Thomas <ma...@apache.org> wrote: > >> 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. >> > > IMHO Those fundamental issues still exist then. Which still lead to a need > of clarity on EG, which was my original question. :)
I still don't see the need. Section 6.3 makes it very clear it is not required to run in a J2EE container. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
