e5a31a4282
Motivation: Shading requires renaming binary components (.so, .dll; for tcnative, epoll, etc). But the rename then requires setting the io.netty.packagePrefix system property on the command line or runtime, which is either a burden or not feasible. If you don't rename the binary components everything appears to work, until a dependency on a second version of the binary component is added. At that point, only one version of the binary will be loaded... which is what shading is supposed to prevent. So for valid shading, the binaries must be renamed. Modifications: Automatically detect the package prefix by comparing the actual class name to the non-shaded expected class name. The expected class name must be obfuscated to prevent shading utilities from changing it. Result: When shading and using binary components, runtime configuration is no longer necessary. Pre-existing shading users that were not renaming the binary components will break, because the packagePrefix previously defaulted to "". Since these pre-existing users had broken configurations that only _appeared_ to work, this breakage is considered a Good Thing. Users may workaround this breakage temporarily by setting -Dio.netty.packagePrefix= to restore packagePrefix to "". Fixes #6963 |
||
---|---|---|
.github | ||
all | ||
bom | ||
buffer | ||
codec | ||
codec-dns | ||
codec-haproxy | ||
codec-http | ||
codec-http2 | ||
codec-memcache | ||
codec-mqtt | ||
codec-redis | ||
codec-smtp | ||
codec-socks | ||
codec-stomp | ||
codec-xml | ||
common | ||
dev-tools | ||
example | ||
handler | ||
handler-proxy | ||
license | ||
microbench | ||
resolver | ||
resolver-dns | ||
tarball | ||
testsuite | ||
testsuite-autobahn | ||
testsuite-osgi | ||
transport | ||
transport-native-epoll | ||
transport-native-kqueue | ||
transport-native-unix-common | ||
transport-native-unix-common-tests | ||
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
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.