Go to file
Trustin Lee b533a1361b Replace UniqueName with Constant and ConstantPool
- Proposed fix for #1824

UniqueName and its subtypes do not allow getting the previously registered instance.  For example, let's assume that a user is running his/her application in an OSGi container with Netty bundles and his server bundle.  Whenever the server bundle is reloaded, the server will try to create a new AttributeKey instance with the same name.  However, Netty bundles were not reloaded at all, so AttributeKey will complain that the name is taken already (by the previously loaded bundle.)

To fix this problem:

- Replaced UniqueName with Constant, AbstractConstant, and ConstantPool.  Better name and better design.

- Sctp/Udt/RxtxChannelOption is not a ChannelOption anymore.  They are just constant providers and ChannelOption is final now.  It's because caching anything that's from outside of netty-transport will lead to ClassCastException on reload, because ChannelOption's constant pool will keep all option objects for reuse.

- Signal implements Constant because we can't ensure its uniqueness anymore by relying on the exception raised by UniqueName's constructor.
2014-02-13 15:14:34 -08:00
all Fix external Javadoc url 2014-02-10 13:40:30 -08:00
buffer [#2187] Always do a volatile read on the refCnt 2014-02-07 09:23:16 +01:00
codec [#1907] LengthFieldPrepender should better extend MessageToMessageEncoder for less memory copies 2014-02-13 14:52:12 -08:00
codec-http [#1876] Make use of proper state machine in WebSocket08FrameDecoder for performance reasons 2014-02-13 14:34:34 -08:00
codec-socks Fix the potential copyright issue in SocksCommonUtils 2014-02-06 15:00:06 -08:00
common Replace UniqueName with Constant and ConstantPool 2014-02-13 15:14:34 -08:00
example Remove a version clause added by mistake 2014-02-08 11:07:58 -08:00
handler Fix the potential copyright issue in SocksCommonUtils 2014-02-06 15:00:06 -08:00
license Add back jzlib license file and notice 2013-02-21 14:00:59 -08:00
microbench [maven-release-plugin] prepare for next development iteration 2014-01-21 08:18:32 +01:00
tarball [maven-release-plugin] prepare for next development iteration 2014-01-21 08:18:32 +01:00
testsuite Allow to cancel non-flushed writes 2014-02-11 19:42:49 +01:00
transport Replace UniqueName with Constant and ConstantPool 2014-02-13 15:14:34 -08:00
transport-rxtx Replace UniqueName with Constant and ConstantPool 2014-02-13 15:14:34 -08:00
transport-sctp Replace UniqueName with Constant and ConstantPool 2014-02-13 15:14:34 -08:00
transport-udt Replace UniqueName with Constant and ConstantPool 2014-02-13 15:14:34 -08:00
.fbfilter.xml Update license headers 2012-06-04 13:31:44 -07:00
.fbprefs Updated Find Bugs configuration 2009-03-04 10:33:09 +00:00
.gitignore Format and partially describe Gitignore 2013-12-10 07:04:38 +01:00
.travis.yml Travis CI branch whitelisting 2013-03-11 09:55:43 +09:00
LICENSE.txt Relicensed to Apache License v2 2009-08-28 07:15:49 +00:00
NOTICE.txt Add back jzlib license file and notice 2013-02-21 14:00:59 -08:00
pom.xml Make the build not fail in JDK8 until we fix Javadoc 2014-02-10 14:11:38 -08:00
README.md Update README.md 2014-01-16 14:38:36 +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

The 'master' branch is where the development of the latest major version lives on. The development of all other major versions takes place in each branch whose name is identical to its major version number. For example, the development of 3.x and 4.x resides in the branch '3' and the branch '4' respectively.