Go to file
Trustin Lee afb46b926f Improve the API design of Http2OrHttpChooser and SpdyOrHttpChooser
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
2015-06-05 11:58:19 +09:00
all [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
buffer Fix regression introduced by f765053ae7 by use Entry after it is recycled 2015-05-27 16:56:20 +02:00
codec [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
codec-dns [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
codec-haproxy [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
codec-http Improve the API design of Http2OrHttpChooser and SpdyOrHttpChooser 2015-06-05 11:58:19 +09:00
codec-http2 Improve the API design of Http2OrHttpChooser and SpdyOrHttpChooser 2015-06-05 11:58:19 +09:00
codec-memcache [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
codec-mqtt [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
codec-socks [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
codec-stomp [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
codec-xml [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
common Let PoolThreadCache work even if allocation and deallocation Thread are different 2015-05-27 14:38:11 +02:00
example Improve the API design of Http2OrHttpChooser and SpdyOrHttpChooser 2015-06-05 11:58:19 +09:00
handler Improve the API design of Http2OrHttpChooser and SpdyOrHttpChooser 2015-06-05 11:58:19 +09:00
handler-proxy [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
license Let PoolThreadCache work even if allocation and deallocation Thread are different 2015-05-27 14:38:11 +02:00
microbench [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
resolver [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
resolver-dns Fix IllegalReferenceCountException in DnsNameResolver 2015-06-03 19:17:56 +09:00
tarball [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
testsuite More meaningful assertion failure message 2015-06-04 12:08:30 +09:00
testsuite-osgi [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
transport [#3837] Null out ByteBuffer[] array once done 2015-06-04 12:33:25 +02:00
transport-native-epoll Linux EPOLL Channel Configuration test unsupported options 2015-06-02 12:54:36 -07:00
transport-rxtx [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
transport-sctp [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
transport-udt [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
.fbprefs Updated Find Bugs configuration 2009-03-04 10:33:09 +00:00
.gitignore Add JVM crash logs to .gitignore 2014-05-18 21:36:54 +09:00
.travis.yml Travis CI branch whitelisting 2013-03-11 09:55:43 +09:00
CONTRIBUTING.md Move the pull request guide to the developer guide 2014-03-12 13:13:58 +09:00
LICENSE.txt Relicensed to Apache License v2 2009-08-28 07:15:49 +00:00
NOTICE.txt Let PoolThreadCache work even if allocation and deallocation Thread are different 2015-05-27 14:38:11 +02:00
pom.xml Remove the verbose:gc flag from the build 2015-05-29 10:43:18 +09:00
README.md Add a link to the 'native transports' page 2014-07-21 12:54:24 -07:00
run-example.sh Add HTTP/2 Netty tiles example 2015-05-18 14:16:54 -07:00

Netty Project

Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients.

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:

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.