Go to file
Norman Maurer cf71e5bae2 Log less confusing message when try to load native library
Motivation:

At the moment we log very confusing messages when trying to load a native library which kind of suggest that the whole loading process failed even if just one mechanism failed and the library could be loaded at the end.

Modifications:

Make the mesage less confusing and also log a successful load of the native library.

Result:

Less confusing logs.
2016-09-13 17:16:02 -07:00
all [maven-release-plugin] prepare for next development iteration 2016-08-26 08:36:54 +02:00
buffer Share code between retain(...) and release(...) implementations. 2016-09-02 21:56:22 +02:00
codec [maven-release-plugin] prepare for next development iteration 2016-08-26 08:36:54 +02:00
codec-haproxy [maven-release-plugin] prepare for next development iteration 2016-08-26 08:36:54 +02:00
codec-http CorsHandler to respect http connection (keep-alive) header. 2016-09-06 07:27:02 +02:00
codec-socks [maven-release-plugin] prepare for next development iteration 2016-08-26 08:36:54 +02:00
common Log less confusing message when try to load native library 2016-09-13 17:16:02 -07:00
example Remove OSGi import of JCTools since it is shaded. 2016-09-13 14:22:29 -07:00
handler Only set lastReadTime if an read actually happened before in IdleStateHandler. 2016-09-13 16:57:37 -07:00
license Let PoolThreadCache work even if allocation and deallocation Thread are different 2015-05-27 14:35:22 +02:00
microbench [maven-release-plugin] prepare for next development iteration 2016-08-26 08:36:54 +02:00
tarball [maven-release-plugin] prepare for next development iteration 2016-08-26 08:36:54 +02:00
testsuite Fix compile error introduced by bac0d4c0e0 2016-09-01 08:39:52 +02:00
testsuite-osgi [maven-release-plugin] prepare for next development iteration 2016-08-26 08:36:54 +02:00
transport Fix javadoc 2016-09-12 06:43:36 -07:00
transport-native-epoll Correct throw ClosedChannelException when attempt to call shutdown*(...) on closed EpollSocketChannel. 2016-09-01 08:16:09 +02:00
transport-rxtx [maven-release-plugin] prepare for next development iteration 2016-08-26 08:36:54 +02:00
transport-sctp [maven-release-plugin] prepare for next development iteration 2016-08-26 08:36:54 +02:00
transport-udt [maven-release-plugin] prepare for next development iteration 2016-08-26 08:36:54 +02:00
.fbprefs Updated Find Bugs configuration 2009-03-04 10:33:09 +00:00
.gitignore Use shaded dependency on JCTools instead of copy and paste 2016-06-10 13:53:28 +02: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:18:14 +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:35:22 +02:00
pom.xml Remove OSGi import of JCTools since it is shaded. 2016-09-13 14:22:29 -07:00
README.md Updating Branches to look section to match the current branching structure of the project 2016-03-10 22:09:30 +01:00
run-example.sh Add logLevel property to enable different log levels for the examples. 2014-11-21 10:48:13 +09: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

Development of all 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.