On 29/01/2015 13:50, Rémy Maucherat wrote: > 2015-01-29 13:57 GMT+01:00 <[email protected]>: > >> Author: markt >> Date: Thu Jan 29 12:57:50 2015 >> New Revision: 1655638 >> >> URL: http://svn.apache.org/r1655638 >> Log: >> Push obtaining the remote host and address down to the SocketWrapper >> >> Modified: >> tomcat/trunk/java/org/apache/coyote/http11/Http11AprProcessor.java >> tomcat/trunk/java/org/apache/coyote/http11/Http11Nio2Processor.java >> tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java >> > This doesn't actually make code smaller (or simpler), so the idea is to > remove these classes to have all IO API specific items in tomcat.util.net ?
Broadly, yes. This is part of what needs to be done to get to a single Http11Processor class rather than than the abstract base class and 3 concrete implementations we have now. I was waiting for some unit tests to complete so I did part of it and then committed it. The rest will follow as time permits. The end goal is to have all of the I/O implementation specific code in Endpoint and SocketWrapper. Endpoint holds the 'per connector' state and SocketWrapper the 'per connection' state. While I am doing some clean-up in Endpoint and SocketWrapper as the opportunity presents itself, I haven't gone over them in detail. I'm sure there is some stuff I have pushed down to Endpoint/SocketWrapper that could be cleaner but I plan to address that later. I'm confident I'll be able to get to a single Http11Processor class. I'm not so sure about the [Ajp|Http11]Protocol classes. There are two parts to that. The I/O specific code in the ConnectionHandlers and the I/O specific configuration options. It might end up being cleaner leaving those broadly as they are. The rough plan I have in my head at the moment is: - Get to a single Http11Processor - Take another look at [Ajp|Http11]Protocol and see if anything else can be pushed down easily - Refactor WebSocket to use the I/O layer directly rather than going via the Servlet API - Review Endpoint & SocketWrapper for clean-up opportunities - Start thinking about HTTP/2.0 Note that some of the changes are am making now are with an eye to the refactoring I plan to do in later stages. I'm sure some of those changes will prove to be not quite what is required and further tweaking will be required. Overall, my aim is to end up with something that is easier to understand, easier to maintain and easier to extend for future features like HTTP/2.0. Personally, I have found the refactored code much easier to work with. As I have made mistakes in the refactoring and triggered unit test failures, debugging those mistakes has simpler and quicker than I have come to expect for I/O layer bugs. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
