Mailing-List: contact announce-help@apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (nike.apache.org: local policy)
Subject: [ANNOUNCEMENT] HttpComponents HttpCore 4.2-alpha1 Released
From: Oleg Kalnichevski <olegk@apache.org>
To: announce@apache.org, private@hc.apache.org, dev@hc.apache.org,
 httpclient-users@hc.apache.org
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 19 Aug 2011 17:25:16 +0200
Message-ID: <1313767516.6528.132.camel@ubuntu>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

The Apache HttpComponents project is pleased to announce the release of
HttpComponents HttpCore 4.2-alpha1. The most notable feature included in
this release is support for connection pools of blocking and
non-blocking HTTP connections. Connection pool components are based on
mature code migrated from HttpClient and HttpAsyncClient modules but
have a slightly different API that makes a better use of Java standard
concurrent primitives. 

Support for connection pools in HttpCore is expected to make development
of client and proxy HTTPservices easier and less error prone.

Please note that new features included in this release are still
considered experimental and their API may change in the future ALPHA
releases. This release also marks the end of support for Java 1.3. As of
this release HttpCore requires Java 1.5 for all its components. Several
classes and methods deprecated between versions 4.0-beta1 and 4.0 GA
(more than two years ago) have been removed in this release.

Download -
<http://hc.apache.org/downloads.cgi>
Release notes -
<http://www.apache.org/dist/httpcomponents/httpcore/RELEASE_NOTES.txt>
HttpComponents site -
<http://hc.apache.org/>

About HttpComponents Core -
HttpCore is a set of low level HTTP transport components that can be
used to build custom client and server side HTTP services with a minimal
footprint. HttpCore supports two I/O models: a blocking I/O model based
on the classic Java I/O and a non-blocking, event driven I/O model based
on Java NIO.  The blocking I/O model may be more appropriate for data
intensive, low latency scenarios, whereas the non-blocking model may be
more appropriate for high latency scenarios where raw data throughput is
less important than the ability to handle thousands of simultaneous HTTP
connections in a resource efficient manner.


--------------------------------------------------------------------- 
To unsubscribe, e-mail: announce-unsubscribe@apache.org 
For additional commands, e-mail: announce-help@apache.org