2e231283cf
Related: #3641 and #3813 Motivation: When setting up an HTTP/1 or HTTP/2 (or SPDY) pipeline, a user usually ends up with adding arbitrary set of handlers. Http2OrHttpChooser and SpdyOrHttpChooser have two abstract methods (create*Handler()) that expect a user to return a single handler, and also have add*Handlers() methods that add the handler returned by create*Handler() to the pipeline as well as the pre-defined set of handlers. The problem is, some users (read: I) don't need all of them or the user wants to add more than one handler. For example, take a look at io.netty.example.http2.tiles.Http2OrHttpHandler, which works around this issue by overriding addHttp2Handlers() and making createHttp2RequestHandler() a no-op. Modifications: - Replace add*Handlers() and create*Handler() with configure*() - Rename getProtocol() to selectProtocol() to make what it does clear - Provide the default implementation of selectProtocol() - Remove SelectedProtocol.UNKNOWN and use null instead, because 'UNKNOWN' is not a protocol - Proper exception handling in the *OrHttpChooser so that the exception is logged and the connection is closed when failed to select a protocol - Make SpdyClient example always use SSL. It was always using SSL anyway. - Implement SslHandshakeCompletionEvent.toString() for debuggability - Remove an orphaned class: JettyNpnSslSession - Add SslHandler.applicationProtocol() to get the name of the application protocol - SSLSession.getProtocol() now returns transport-layer protocol name only, so that it conforms to its contract. Result: - *OrHttpChooser have better API. - *OrHttpChooser handle protocol selection failure properly. - SSLSession.getProtocol() now conforms to its contract. - SpdyClient example works with SpdyServer example out of the box |
||
|---|---|---|
| all | ||
| buffer | ||
| codec | ||
| codec-dns | ||
| codec-haproxy | ||
| codec-http | ||
| codec-http2 | ||
| codec-memcache | ||
| codec-mqtt | ||
| codec-socks | ||
| codec-stomp | ||
| codec-xml | ||
| common | ||
| example | ||
| handler | ||
| handler-proxy | ||
| license | ||
| microbench | ||
| resolver | ||
| resolver-dns | ||
| tarball | ||
| testsuite | ||
| testsuite-osgi | ||
| transport | ||
| transport-native-epoll | ||
| transport-rxtx | ||
| transport-sctp | ||
| transport-udt | ||
| .fbprefs | ||
| .gitignore | ||
| .travis.yml | ||
| CONTRIBUTING.md | ||
| LICENSE.txt | ||
| NOTICE.txt | ||
| pom.xml | ||
| README.md | ||
| run-example.sh | ||
Netty Project
Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients.
Links
How to build
For the detailed information about building and developing Netty, please visit the developer guide. This page only gives very basic information.
You require the following to build Netty:
- Latest stable Oracle JDK 7
- Latest stable Apache Maven
- If you are on Linux, you need additional development packages installed on your system, because you'll build the native transport.
Note that this is build-time requirement. JDK 5 (for 3.x) or 6 (for 4.0+) is enough to run your Netty-based application.
Branches to look
The 'master' branch is where the development of the latest major version lives on. The development of all other versions takes place in each branch whose name is identical to <majorVersion>.<minorVersion>. For example, the development of 3.9 and 4.0 resides in the branch '3.9' and the branch '4.0' respectively.