On 11/02/2013 19:38, Williams, Nick wrote: > -----Original Message----- > From: Mark Thomas [mailto:ma...@apache.org] > Sent: Monday, February 11, 2013 10:46 AM > To: Tomcat Developers List > Subject: Re: EL 3.0, HttpSessionIdListener, > HttpServletRequest#changeSessionId() > >> For WebSocket I automate it a little by using javap on the spec repository >> and on Tomcat and then fixing the diffs to the public API by hand. > > Here's what I did. Tell me if this sounds about right. I may be way off base > here.
Looks OK to me. <snip/> > I then compared servlet-api.jar.contents and > javax.servlet-api-3.1-b05.jar.contents (I used FileMerge) and came up with > this: > > javax.servlet.http.HttpServletRequest: changeSessionId() missing in Tomcat Yep. > javax.servlet.http.HttpServletRequest: public abstract void > upgrade(javax.servlet.http.ProtocolHandler) throws IOException in Tomcat > should be: > public abstract <T extends javax.servlet.http.HttpUpgradeHandler> T > upgrade(java.lang.Class<T>) throws IOException I argued for (and got) a name change from ProtocolHandler to HttpUpgradeHandler that hasn't been implemented yet. Name changes are usually easier for committers to handle though the IDE since the effort is minimal but the diff can be big and reviewing a large diff is a pain. I've just implemented this. I haven't done anything about the method signature change. > javax.servlet.http.HttpServletRequestWrapper: changeSessionId() missing Yep. Missing feature. > javax.servlet.http.HttpServletRequestWrapper: public void > upgrade(javax.servlet.http.ProtocolHandler) throws IOException in Tomcat > should be: > public <T extends javax.servlet.http.HttpUpgradeHandler> T > upgrade(java.lang.Class<T>) throws IOException > javax.servlet.http.HttpSessionIdListener: missing in Tomcat > javax.servlet.http.HttpUpgradeHandler: missing in Tomcat Missing features. > javax.servlet.http.NoBodyOutputStream: public boolean canWrite() in Tomcat > should be: > public boolean isReady() Another naming change that I hadn't caught up with. Done. > javax.servlet.http.NoBodyResponse: overridden method > setContentLengthLong(long) in Tomcat is not overridden in spec > javax.servlet.http.NoBodyResponse: overridden method setHeader(String, > String) in Tomcat is not overridden in spec > javax.servlet.http.NoBodyResponse: overridden method addheader(String, > String) in Tomcat is not overridden in spec > javax.servlet.http.NoBodyResponse: overridden method setIntHeader(String, > int) in Tomcat is not overridden in spec > javax.servlet.http.NoBodyResponse: overridden method addIntHeader(String, > int) in Tomcat is not overridden in spec Not an issue. > javax.servlet.http.NoBodyResponse: static initializer in spec not present in > Tomcat (is this even a problem?) This sort of thing is not an issue. It is only public and protected API we need to worry about. > javax.servlet.http.ProtocolHandler: superfluous Tomcat class does not exist > in specification See above. > javax.servlet.http.WebConnection: should extend java.lang.AutoCloseable, does > not in Tomcat Missing feature. > javax.servlet.GenericServlet: static initializer in spec not present in > Tomcat (is this even a problem?) > javax.servlet.HttpConstraintElement: static initializer in Tomcat not present > in spec (is this even a problem?) > javax.servlet.HttpMethodConstraintElement: static initializer in Tomcat not > present in spec (is this even a problem?) See above. > javax.servlet.ServletOutputStream: public boolean canWrite() in Tomcat should > be: > public boolean isReady() Rename. See above. Fixed. > A lot of that is WebSocket related, methinks (upgrade, upgrade handler, no > body response, protocol handler), so those are yours, and I don't think the > static initializers matter (though I could be wrong). The rest of it (change > session ID, session ID change listener, WebConnection needing to extend > AutoCloseable, and the two canWrites needing to be isReady) seem like some > pretty simple things that I could knock out in one evening, assuming my > contributions wouldn't be stepping on anyone's toes. Nope. This is all Servlet 3.1 stuff. > Before I actually do any work on anything I'd love some feedback on my > analysis. See above. The biggest part of the work in Servlet 3.1 is the non-blocking IO support. Filip wrote an implementation for NIO only. The other two connectors are not implemented. Further, after using the non-blocking IO for WebSockets I think there is a issue in that the underlying assumption that there is only ever one thread accessing a socket is not correct. Removing that limitation in the main connector code is going to be non-trivial. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
