+1 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: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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
