On 29/10/2013 13:41, Romain Manni-Bucau wrote: > Yes but if it runs in a JavaEE container (J2EE doesn't exist anymore > if i'm not mistaken)
Indeed but it is quicker to type J2EE and everyone knows what I mean. > or at least a servlet container what is the minimum required? As the specification is currently written I'd say it requires that any implementation in a JavaEE web container requires at least Servlet 3.0 as it requires the use of the scanning mechanism introduced in 3.0. Some EG members did express a desire to implement it on Servlet 2.5 containers. I don't know if anyone has or, if they have, how they addressed the scanning issue. If Tomcat's JSR-356 implementation was back-ported to 6.0.x (I have no desire to do that) then I guess the scanning would have to be back-ported in some form as well. I suspect it could get messy quite quickly. The connector code would certainly be painful to back-port as none of the refactoring that significantly reduced the duplication exists in 6.0.x. If there is a desire to implement JSR-356 in Servlet 2.5 or earlier, I'd suggest changing section 6.2 so it applies to Servlet 3.0 and later containers and changing section 6.3 so it applies to Servlet 2.5 or earlier containers and any other non-JavaEE container. Mark > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
