On Tue, Oct 29, 2013 at 4:02 PM, Romain Manni-Bucau <rmannibu...@gmail.com>wrote:
> +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. > +1 Spec clarification would help in cases like this one. > > > 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 > >
