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. :) cheers Niki > The intention of the WebSocket EG was that a specification compliant > WebSocket server container could be implemented on a stand-along basis > without having to implement any other J2EE specs. I don't believe there > is anything in the WebSocket spec that contradicts that. For example, > see section 6.3 which explicitly references implementations that do not > include a Servlet container. > > > The dependency is more hidden to me. Mark, I > > understand your point by saying ok when implementing the websocket > > container I don't use servlet spec APIs. The javax.servlet APIs are not > > used in the implementation, are they? > > In Tomcat's implementation, yes they are because that was how I opted to > implement it. My intention was to produce a container neutral WebSocket > implementation. > > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >