Yes but if it runs in a JavaEE container (J2EE doesn't exist anymore if i'm not mistaken) or at least a servlet container what is the minimum required? Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau
2013/10/29 Mark Thomas <ma...@apache.org>: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
