date:20080120


On Mon, 2008-01-21 at 00:09 +, sebb wrote:
> On 20/01/2008, Roland Weber <[EMAIL PROTECTED]> wrote:
> > sebb wrote:
> > > Not sure if this is just me, but when I ran
> > >
> > > mvn package assembly:assembly
> > >
> > > a directory tree archive-tmp was created under target.
> > >
> > > This contains lots of numbered directories and example, main, site and 
> > > test
> > >
> > > I would have thought this should be deleted by the script?
> >
> > But then it wouldn't be able to do incremental assemblies, right?
> 
> No idea ;-)
> 
> Seems strange that the example, main, site and test trees have no files in 
> them.
> 
> Also, I tried redoing the "mvn package assembly:assembly" and it did
> not recompile anything, but it did create _another_ 20 numbered
> directories.
> 
> Looks like it may be something to do with the line-feed processing, as
> there seem to be 4 copies of each file, 2 in DOS format and 2 in Unix
> format.
> 
> I would have though that those should be deleted after creating the archives.
> 
> > It doesn't delete the compiled classes either after packaging
> > them as a jar.
> >
> 
> Indeed not.
> 

Sebastian,

My understanding is the content of 'target' directory is meant to be for
Maven use only. It does not get deleted automatically unless 'clean'
phase is explicitly requested. 

Oleg

> > cheers,
> >   Roland
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Problems in Maven build

On 20/01/2008, Roland Weber <[EMAIL PROTECTED]> wrote:
> sebb wrote:
> > Not sure if this is just me, but when I ran
> >
> > mvn package assembly:assembly
> >
> > a directory tree archive-tmp was created under target.
> >
> > This contains lots of numbered directories and example, main, site and test
> >
> > I would have thought this should be deleted by the script?
>
> But then it wouldn't be able to do incremental assemblies, right?

No idea ;-)

Seems strange that the example, main, site and test trees have no files in them.

Also, I tried redoing the "mvn package assembly:assembly" and it did
not recompile anything, but it did create _another_ 20 numbered
directories.

Looks like it may be something to do with the line-feed processing, as
there seem to be 4 copies of each file, 2 in DOS format and 2 in Unix
format.

I would have though that those should be deleted after creating the archives.

> It doesn't delete the compiled classes either after packaging
> them as a jar.
>

Indeed not.

> cheers,
>   Roland
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] HttpComponents Core 4.0-beta1 release

2008-01-20 Thread ant elder

+1

   ...ant

On Jan 20, 2008 5:18 PM, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:

> Please vote on releasing these packages as HttpComponents Core 4.0-beta1.
> The vote is open for the
> next 72 hours, and only votes from HttpComponents PMC members are binding.
> The vote passes if at least
> three binding +1 votes are cast.
>
> Packages:
> http://people.apache.org/~olegk/httpcore-4.0-beta1/packages/
>
> Release notes:
> http://people.apache.org/~olegk/httpcore-4.0-beta1/RELEASE_NOTES.txt
>
> --
>  Vote:  HttpComponents Core 4.0-beta1 release
>  [ ] +1 Release the packages as HttpComponents Core 4.0-beta1.
>  [ ] -1 I am against releasing the packages (must include a reason).
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: [VOTE] HttpComponents Core 4.0-beta1 release

2008-01-20 Thread Andrea Selva

+1

On Jan 20, 2008 7:25 PM, Roland Weber <[EMAIL PROTECTED]> wrote:

> +1
>
> Oleg Kalnichevski wrote:
> > Please vote on releasing these packages as HttpComponents Core 4.0-beta1.
> The vote is open for the
> > next 72 hours, and only votes from HttpComponents PMC members are
> binding. The vote passes if at least
> > three binding +1 votes are cast.
> >
> > Packages:
> > http://people.apache.org/~olegk/httpcore-4.0-beta1/packages/
> >
> > Release notes:
> > http://people.apache.org/~olegk/httpcore-4.0-beta1/RELEASE_NOTES.txt
> >
> >
> --
> >  Vote:  HttpComponents Core 4.0-beta1 release
> >  [ ] +1 Release the packages as HttpComponents Core 4.0-beta1.
> >  [ ] -1 I am against releasing the packages (must include a reason).
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

[jira] Resolved: (HTTPCLIENT-729) move HttpRoute and related classes to separate package

2008-01-20 Thread Roland Weber (JIRA)


 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roland Weber resolved HTTPCLIENT-729.
-

Resolution: Fixed

API classes moved to org.apache.http.conn.routing.
Implementation classes remain in place for now,
might be moved later.

> move HttpRoute and related classes to separate package
> --
>
> Key: HTTPCLIENT-729
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-729
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpConn
>Affects Versions: 4.0 Alpha 2
>Reporter: Roland Weber
>Assignee: Roland Weber
>Priority: Minor
> Fix For: 4.0 Alpha 3
>
>
> The route-related stuff in o.a.h.conn is detached from the rest of the 
> connection management API.
> Move HttpRoute, RouteTracker, HttpRouteDirector, HttpRoutePlanner to 
> o.a.h.conn.route or ...routing.
> Implementation classes have a dependency on Scheme and SchemeRegistry in 
> o.a.h.conn,
> but that does not introduce a recursive dependency between packages.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Problems in Maven build

sebb wrote:
> Not sure if this is just me, but when I ran
> 
> mvn package assembly:assembly
> 
> a directory tree archive-tmp was created under target.
> 
> This contains lots of numbered directories and example, main, site and test
> 
> I would have thought this should be deleted by the script?

But then it wouldn't be able to do incremental assemblies, right?
It doesn't delete the compiled classes either after packaging
them as a jar.

cheers,
  Roland


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Problems in Maven build

Not sure if this is just me, but when I ran

mvn package assembly:assembly

a directory tree archive-tmp was created under target.

This contains lots of numbered directories and example, main, site and test

I would have thought this should be deleted by the script?

S///

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] HttpComponents Core 4.0-beta1 release

+1

Oleg Kalnichevski wrote:
> Please vote on releasing these packages as HttpComponents Core 4.0-beta1. The 
> vote is open for the 
> next 72 hours, and only votes from HttpComponents PMC members are binding. 
> The vote passes if at least 
> three binding +1 votes are cast.
> 
> Packages:
> http://people.apache.org/~olegk/httpcore-4.0-beta1/packages/
> 
> Release notes:
> http://people.apache.org/~olegk/httpcore-4.0-beta1/RELEASE_NOTES.txt
> 
> --
>  Vote:  HttpComponents Core 4.0-beta1 release
>  [ ] +1 Release the packages as HttpComponents Core 4.0-beta1.
>  [ ] -1 I am against releasing the packages (must include a reason). 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] HttpComponents Core 4.0-beta1 release

+1

On 20/01/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
> +1
>
> Oleg
>
> On Sun, 2008-01-20 at 18:18 +0100, Oleg Kalnichevski wrote:
> > Please vote on releasing these packages as HttpComponents Core 4.0-beta1. 
> > The vote is open for the
> > next 72 hours, and only votes from HttpComponents PMC members are binding. 
> > The vote passes if at least
> > three binding +1 votes are cast.
> >
> > Packages:
> > http://people.apache.org/~olegk/httpcore-4.0-beta1/packages/
> >
> > Release notes:
> > http://people.apache.org/~olegk/httpcore-4.0-beta1/RELEASE_NOTES.txt
> >
> > --
> >  Vote:  HttpComponents Core 4.0-beta1 release
> >  [ ] +1 Release the packages as HttpComponents Core 4.0-beta1.
> >  [ ] -1 I am against releasing the packages (must include a reason).
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] HttpComponents Core 4.0-beta1 release

+1

Oleg

On Sun, 2008-01-20 at 18:18 +0100, Oleg Kalnichevski wrote:
> Please vote on releasing these packages as HttpComponents Core 4.0-beta1. The 
> vote is open for the 
> next 72 hours, and only votes from HttpComponents PMC members are binding. 
> The vote passes if at least 
> three binding +1 votes are cast.
> 
> Packages:
> http://people.apache.org/~olegk/httpcore-4.0-beta1/packages/
> 
> Release notes:
> http://people.apache.org/~olegk/httpcore-4.0-beta1/RELEASE_NOTES.txt
> 
> --
>  Vote:  HttpComponents Core 4.0-beta1 release
>  [ ] +1 Release the packages as HttpComponents Core 4.0-beta1.
>  [ ] -1 I am against releasing the packages (must include a reason). 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE] HttpComponents Core 4.0-beta1 release

Please vote on releasing these packages as HttpComponents Core 4.0-beta1. The 
vote is open for the 
next 72 hours, and only votes from HttpComponents PMC members are binding. The 
vote passes if at least 
three binding +1 votes are cast.

Packages:
http://people.apache.org/~olegk/httpcore-4.0-beta1/packages/

Release notes:
http://people.apache.org/~olegk/httpcore-4.0-beta1/RELEASE_NOTES.txt

--
 Vote:  HttpComponents Core 4.0-beta1 release
 [ ] +1 Release the packages as HttpComponents Core 4.0-beta1.
 [ ] -1 I am against releasing the packages (must include a reason). 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [HttpCore] HttpCore 4.0-beta1 release packages preview (4th take)

2008-01-20 Thread ant elder

Looks good and it builds ok with all test passing for me now.

   ...ant

On Jan 20, 2008 1:39 PM, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:

> Sebastian et al
>
> The problem appears to have been fixed. Please feel free to test the
> latest SVN snapshots.
>
> The preview packages can be found below:
>
>
> http://people.apache.org/~olegk/httpcore-4.0-beta1-preview/RELEASE_NOTES.txt
> http://people.apache.org/~olegk/httpcore-4.0-beta1-preview/packages/
>
> I would like to cut the final release packages and call a vote on the
> release later today.
>
> Oleg
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Status of Wiki migration

Hi folks,

I have moved all pages referenced from the "User Information"
section of our new wiki, plus the ReferenceMaterials from the
"Developer Information" section:
http://wiki.apache.org/HttpComponents/

The rest will follow some other weekend. You've had enough
Wiki spam for today :-)

cheers,
  Roland

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Httpcomponents Wiki] Update of "FrontPage" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" 
for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/HttpComponents/FrontPage

The comment on the change is:
repointed remaining user links

--
  It points to !JavaDocs and example code not linked from this wiki.
  
  If you are considering the old codebase versus the new components, the
- [http://wiki.apache.org/jakarta-httpclient/HttpClient3vsHttpClient4vsHttpCore 
benchmark results]
+ [wiki:Self:HttpClient3vsHttpClient4vsHttpCore benchmark results]
  could be of use.
  [[BR]]
  If you are stuck with a very old JVM and have to use HTTPS, you need a
- [http://wiki.apache.org/jakarta-httpclient/AlternativeJSSE JSSE 
Implementation].
+ [wiki:Self:AlternativeJSSE JSSE Implementation].
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Jakarta-httpclient Wiki] Update of "HttpClient3vsHttpClient4vsHttpCore" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-httpclient 
Wiki" for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/jakarta-httpclient/HttpClient3vsHttpClient4vsHttpCore

--
- = Client side HTTP performance benchmarks =
+ #DEPRECATED
  
- '''BIG FAT DISCLAIMER''': These benchmarks are NOT based on any scientific 
methodology so the numbers are likely to be non-precise  
+ This page has been 
[http://wiki.apache.org/HttpComponents/HttpClient3vsHttpClient4vsHttpCore moved]
+ to the new [http://wiki.apache.org/HttpComponents/ HttpComponents Wiki].
  
- == HttpClient 3.x code ==
- 
- {{{
- public static void main(String[] args) throws Exception {
- if (args.length < 2) {
- System.out.println("Usage:  ");
- System.exit(-1);
- }
- String targetURI = args[0];
- int n = Integer.parseInt(args[1]);
- 
- HttpClient httpclient = new HttpClient();
- httpclient.getParams().setVersion(
- HttpVersion.HTTP_1_1);
- httpclient.getParams().setBooleanParameter(
- HttpMethodParams.USE_EXPECT_CONTINUE, false);
- httpclient.getHttpConnectionManager().getParams()
- .setStaleCheckingEnabled(false);
- 
- GetMethod httpget = new GetMethod(targetURI);
- 
- byte[] buffer = new byte[4096];
- 
- long startTime;
- long finishTime;
- int successCount = 0;
- int failureCount = 0;
- String serverName = "unknown";
- long total = 0;
- long contentLen = 0;
- long totalContentLen = 0;
- 
- startTime = System.currentTimeMillis();
- for (int i = 0; i < n; i++) {
- try {
- httpclient.executeMethod(httpget);
- InputStream instream = httpget.getResponseBodyAsStream();
- contentLen = 0;
- if (instream != null) {
- int l = 0;
- while ((l = instream.read(buffer)) != -1) {
- total += l;
- contentLen += l;
- }
- }
- successCount++;
- totalContentLen += contentLen;
- } catch (IOException ex) {
- failureCount++;
- } finally {
- httpget.releaseConnection();
- }
- }
- finishTime = System.currentTimeMillis();
- 
- Header header = httpget.getResponseHeader("Server");
- if (header != null) {
- serverName = header.getValue();
- }
- 
- float totalTimeSec = (float) (finishTime - startTime) / 1000;
- float reqsPerSec = (float) successCount / totalTimeSec; 
- float timePerReqMs = (float) (finishTime - startTime) / (float) 
successCount; 
- 
- System.out.print("Server Software:\t");
- System.out.println(serverName);
- System.out.println();
- System.out.print("Document URI:\t\t");
- System.out.println(targetURI);
- System.out.print("Document Length:\t");
- System.out.print(contentLen);
- System.out.println(" bytes");
- System.out.println();
- System.out.print("Time taken for tests:\t");
- System.out.print(totalTimeSec);
- System.out.println(" seconds");
- System.out.print("Complete requests:\t");
- System.out.println(successCount);
- System.out.print("Failed requests:\t");
- System.out.println(failureCount);
- System.out.print("Content transferred:\t");
- System.out.print(total);
- System.out.println(" bytes");
- System.out.print("Requests per second:\t");
- System.out.print(reqsPerSec);
- System.out.println(" [#/sec] (mean)");
- System.out.print("Time per request:\t");
- System.out.print(timePerReqMs);
- System.out.println(" [ms] (mean)");
- }
- 
- }}}
- 
- == HttpClient 4.x code ==
- 
- {{{
- if (args.length < 2) {
- System.out.println("Usage:  ");
- System.exit(-1);
- }
- String targetURI = args[0];
- int n = Integer.parseInt(args[1]);
- 
- BasicHttpParams params = new BasicHttpParams();
- params.setParameter(HttpProtocolParams.PROTOCOL_VERSION, 
- HttpVersion.HTTP_1_1);
- params.setBooleanParameter(HttpProtocolParams.USE_EXPECT_CONTINUE, 
- false);
- params.setBooleanParameter(HttpConnectionParams.STALE_CONNECTION_CHECK, 
- false);
- params.setIntParameter(HttpConnectionParams.SOCKET_BUFFER_SIZE, 
- 2 * 1024);
- 
- DefaultHttpClient httpclient = new DefaultHttpClient(params);
- 
- HttpGet httpget = new HttpGet(targetURI);
- 
- byte[] buffer = new byte[4096];
- 
- long startTime;
- long finishTime;
- int successCount = 0;
- int failureCount = 0;
- String serverName = "unknown";
- long total = 0;
- long contentLen = 0;
- long totalContentLen = 0;
- 
- startTime = System.currentTimeMillis();
- for (int i = 0; i < n; i++) {
-

[Httpcomponents Wiki] Update of "HttpClient3vsHttpClient4vsHttpCore" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" 
for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/HttpComponents/HttpClient3vsHttpClient4vsHttpCore

New page:
= Client side HTTP performance benchmarks =

'''BIG FAT DISCLAIMER''': These benchmarks are NOT based on any scientific 
methodology so the numbers are likely to be non-precise  

== HttpClient 3.x code ==

{{{
public static void main(String[] args) throws Exception {
if (args.length < 2) {
System.out.println("Usage:  ");
System.exit(-1);
}
String targetURI = args[0];
int n = Integer.parseInt(args[1]);

HttpClient httpclient = new HttpClient();
httpclient.getParams().setVersion(
HttpVersion.HTTP_1_1);
httpclient.getParams().setBooleanParameter(
HttpMethodParams.USE_EXPECT_CONTINUE, false);
httpclient.getHttpConnectionManager().getParams()
.setStaleCheckingEnabled(false);

GetMethod httpget = new GetMethod(targetURI);

byte[] buffer = new byte[4096];

long startTime;
long finishTime;
int successCount = 0;
int failureCount = 0;
String serverName = "unknown";
long total = 0;
long contentLen = 0;
long totalContentLen = 0;

startTime = System.currentTimeMillis();
for (int i = 0; i < n; i++) {
try {
httpclient.executeMethod(httpget);
InputStream instream = httpget.getResponseBodyAsStream();
contentLen = 0;
if (instream != null) {
int l = 0;
while ((l = instream.read(buffer)) != -1) {
total += l;
contentLen += l;
}
}
successCount++;
totalContentLen += contentLen;
} catch (IOException ex) {
failureCount++;
} finally {
httpget.releaseConnection();
}
}
finishTime = System.currentTimeMillis();

Header header = httpget.getResponseHeader("Server");
if (header != null) {
serverName = header.getValue();
}

float totalTimeSec = (float) (finishTime - startTime) / 1000;
float reqsPerSec = (float) successCount / totalTimeSec; 
float timePerReqMs = (float) (finishTime - startTime) / (float) 
successCount; 

System.out.print("Server Software:\t");
System.out.println(serverName);
System.out.println();
System.out.print("Document URI:\t\t");
System.out.println(targetURI);
System.out.print("Document Length:\t");
System.out.print(contentLen);
System.out.println(" bytes");
System.out.println();
System.out.print("Time taken for tests:\t");
System.out.print(totalTimeSec);
System.out.println(" seconds");
System.out.print("Complete requests:\t");
System.out.println(successCount);
System.out.print("Failed requests:\t");
System.out.println(failureCount);
System.out.print("Content transferred:\t");
System.out.print(total);
System.out.println(" bytes");
System.out.print("Requests per second:\t");
System.out.print(reqsPerSec);
System.out.println(" [#/sec] (mean)");
System.out.print("Time per request:\t");
System.out.print(timePerReqMs);
System.out.println(" [ms] (mean)");
}

}}}

== HttpClient 4.x code ==

{{{
if (args.length < 2) {
System.out.println("Usage:  ");
System.exit(-1);
}
String targetURI = args[0];
int n = Integer.parseInt(args[1]);

BasicHttpParams params = new BasicHttpParams();
params.setParameter(HttpProtocolParams.PROTOCOL_VERSION, 
HttpVersion.HTTP_1_1);
params.setBooleanParameter(HttpProtocolParams.USE_EXPECT_CONTINUE, 
false);
params.setBooleanParameter(HttpConnectionParams.STALE_CONNECTION_CHECK, 
false);
params.setIntParameter(HttpConnectionParams.SOCKET_BUFFER_SIZE, 
2 * 1024);

DefaultHttpClient httpclient = new DefaultHttpClient(params);

HttpGet httpget = new HttpGet(targetURI);

byte[] buffer = new byte[4096];

long startTime;
long finishTime;
int successCount = 0;
int failureCount = 0;
String serverName = "unknown";
long total = 0;
long contentLen = 0;
long totalContentLen = 0;

startTime = System.currentTimeMillis();
for (int i = 0; i < n; i++) {
HttpResponse response = httpclient.execute(httpget);
HttpEntity entity = response.getEntity();
if (entity != null) {
InputStream instream = entity.getContent();
try {
contentLen = 0;
if (instream != null) {
int l = 0;
while ((l = instream.read(buffer)) != -1) {
total += l;
contentLen += l;
}
}
successCount++;

[Jakarta-httpclient Wiki] Update of "AlternativeJSSE" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-httpclient 
Wiki" for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/jakarta-httpclient/AlternativeJSSE

--
+ #DEPRECATED
- = JSSE Implementations =
- HttpClient does not come with support for SSL/TLS because it doesn't have to.
- Both security protocols are for the transport layer, while the HTTP protocol
- operates on top of the transport layer. You can mix and match HttpClient with
- any independent SSL/TLS implementation. Our
- [http://jakarta.apache.org/commons/httpclient/sslguide.html SSL/TLS guide]
- explains how to do this.
- The standard [http://java.sun.com/products/jsse/reference/api/index.html Java 
API for SSL/TLS]
- is called [http://java.sun.com/products/jsse/index.jsp JSSE (Java Secure 
Socket Extension)].
- This page lists some JSSE providers, that is implementations of the API, 
which you can use.
- It starts with JSSE providers that are bundled with JDKs, then follow 
independent packages.
  
+ This page has been [http://wiki.apache.org/HttpComponents/AlternativeJSSE 
moved]
+ to the new [http://wiki.apache.org/HttpComponents/ HttpComponents Wiki].
- Some of the [http://jakarta.apache.org/commons/httpclient/sslguide.html SSL 
code]
- in the HttpClient contrib package is hard-coded against the SUN JSSE provider,
- since classes under com.sun.* are referenced. If you are using a different 
provider,
- you have to adapt the code to use the respective API of that provider.
- Problems you may encounter with some JSSE implementations are sometimes 
caused by the fact
- that the secure sockets provided not always correctly implement all socket 
operations
- used by HttpClient.
  
- 
- == SUN JSSE ==
- SUN JDKs since 1.4 are shipped with the SUN JSSE provider.
- There is a separate package that can be downloaded and installed for older 
JDKs.
- The SUN JSSE provider is reported to be stable for use with HttpClient since 
JDK 1.4.2.
- Older versions, and the separate download packages for older JDKs, are 
reported to cause problems.
- 
- 
- == IBM JSSE ==
- IBM JDKs ship with an IBM JSSE provider replacing the one from SUN. Here is 
the
- 
[http://www-128.ibm.com/developerworks/java/jdk/security/142/secguides/jssedocs/JSSERefGuide.html
 documentation]
- for the JSSE. Platform specific security information for the IBM JDK 1.4.2 is 
available
- [http://www-128.ibm.com/developerworks/java/jdk/security/142/ here].
- Information about older JDKs seems to be unavailable or is well hidden.
- 
- 
- == JESSIE ==
- [http://www.nongnu.org/jessie/ JESSIE] stands for ''JESSIE Executes Secure 
Sockets In Excess''.
- It is a free implementation of JSSE with a relaxed GNU license.
- 
- 
- == SSLava ==
- [http://www.oracle.com/technology/products/id_mgmt/phaos/prod_doc.html#ssl 
Oracle Phaos SSLava]
- 
- 
- == iSaSiLk ==
- Developed at the Technical University of Graz,
- [http://jce.iaik.tugraz.at/products/02_isasilk/index.php iSaSiLk]
- is not a cheap, but a good SSL/TLS implementation.
- 
[http://mail-archives.apache.org/mod_mbox/jakarta-httpclient-dev/200505.mbox/[EMAIL
 PROTECTED] Recommended by Oleg.]
- 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Httpcomponents Wiki] Update of "AlternativeJSSE" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" 
for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/HttpComponents/AlternativeJSSE

The comment on the change is:
updated some links

New page:
= JSSE Implementations =
HttpClient does not come with support for SSL/TLS because it doesn't have to.
Both security protocols are for the transport layer, while the HTTP protocol
operates on top of the transport layer. You can mix and match HttpClient with
any independent SSL/TLS implementation. Our
[http://hc.apache.org/httpclient-3.x/sslguide.html SSL/TLS guide]
explains how to do this.
The standard 
[http://java.sun.com/j2se/1.4.2/docs/guide/security/jsse/JSSERefGuide.html#KeyClasses
 Java API for SSL/TLS]
is called [http://java.sun.com/products/jsse/index.jsp JSSE (Java Secure Socket 
Extension)].
This page lists some JSSE providers, that is implementations of the API, which 
you can use.
It starts with JSSE providers that are bundled with JDKs, then follow 
independent packages.

Some of the [http://hc.apache.org/httpclient-3.x/sslguide.html SSL code]
in the HttpClient contrib package is hard-coded against the SUN JSSE provider,
since classes under com.sun.* are referenced. If you are using a different 
provider,
you have to adapt the code to use the respective API of that provider.
Problems you may encounter with some JSSE implementations are sometimes caused 
by the fact
that the secure sockets provided not always correctly implement all socket 
operations
used by HttpClient.


== SUN JSSE ==
SUN JDKs since 1.4 are shipped with the SUN JSSE provider.
There is a separate package that can be downloaded and installed for older JDKs.
The SUN JSSE provider is reported to be stable for use with HttpClient since 
JDK 1.4.2.
Older versions, and the separate download packages for older JDKs, are reported 
to cause problems.


== IBM JSSE ==
IBM JDKs ship with an IBM JSSE provider replacing the one from SUN. Here is the
[http://www-128.ibm.com/developerworks/java/jdk/security/142/secguides/jssedocs/JSSERefGuide.html
 documentation]
for the JSSE. Platform specific security information for the IBM JDK 1.4.2 is 
available
[http://www-128.ibm.com/developerworks/java/jdk/security/142/ here].
Information about older JDKs seems to be unavailable or is well hidden.


== JESSIE ==
[http://www.nongnu.org/jessie/ JESSIE] stands for ''JESSIE Executes Secure 
Sockets In Excess''.
It is a free implementation of JSSE with a relaxed GNU license.


== SSLava ==
[http://www.oracle.com/technology/products/id_mgmt/phaos/prod_doc.html#ssl 
Oracle Phaos SSLava]


== iSaSiLk ==
Developed at the Technical University of Graz,
[http://jce.iaik.tugraz.at/products/02_isasilk/index.php iSaSiLk]
is not a cheap, but a good SSL/TLS implementation.
[http://mail-archives.apache.org/mod_mbox/jakarta-httpcomponents-dev/200505.mbox/[EMAIL
 PROTECTED] Recommended by Oleg.]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Jakarta-httpclient Wiki] Update of "FrontPage" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-httpclient 
Wiki" for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/jakarta-httpclient/FrontPage

The comment on the change is:
added note about the Wiki migration in progress

--
  ##language:en
  #pragma section-numbers off
  
- = Welcome to the HttpComponents Wiki =
+ = Welcome to the old HttpComponents Wiki =
  
- This wiki provides additional documentation for HttpClient and 
HttpComponents.  Formal documentation is available from the 
[http://hc.apache.org/ HttpComponents website].  Users are encouraged to 
contribute information to this wiki that may be useful to others.  Please note 
that as an anti-spam measure, you must be logged in to edit pages.  You can 
user [UserPreferences] to create an account or login.
+ ''The information contained in this Wiki is being moved to the
+ [http://wiki.apache.org/HttpComponents/ new HttpComponents Wiki].
+ We apologize for the inconveniences during the transition.''
  
- The HttpComponents wiki is a part of the [wiki:ApacheGeneral:FrontPage big 
Apache Wiki Farm].
+ This wiki provides additional documentation for HttpClient and 
HttpComponents.  Formal documentation is available from the 
[http://hc.apache.org/ HttpComponents website].  Users are encouraged to 
contribute information to the new wiki that may be useful to others.
  
- If you're new to wikis you might want to read HelpForBeginners to get an idea 
of how they work and how you can contribute.
+ The !HttpComponents Wiki is a part of the big [http://wiki.apache.org/ Apache 
Wiki Farm].
  
  == Table of Contents ==
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Jakarta-httpclient Wiki] Update of "FrequentlyAskedNTLMQuestions" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-httpclient 
Wiki" for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/jakarta-httpclient/FrequentlyAskedNTLMQuestions

--
- #pragma section-numbers 2
+ #DEPRECATED
  
- = Frequently Asked Questions About NTLM =
+ This page has been 
[http://wiki.apache.org/HttpComponents/FrequentlyAskedNTLMQuestions moved]
+ to the new [http://wiki.apache.org/HttpComponents/ HttpComponents Wiki].
  
- 
- [[TableOfContents]]
- 
- 
- == What is NTLM? ==
- 
- NTLM is a proprietary protocol conceived by Microsoft. It can be used,
- among other things, to authenticate against Microsoft HTTP servers and
- proxies. There is no official, publicly available, complete documentation of 
the protocol.
- Most of the information that can be found on the internet had to be
- gathered through reverse engineering.
- There are two versions of the NTLM protocol, commonly
- referred to as NTLMv1 (version 1) and NTLMv2 (version 2).
- There's also a stripped-down version of NTLMv2 called LMv2 mentioned
- in the [http://jcifs.samba.org/src/docs/faq.html#ntlmv2 jCIFS FAQ].
- 
- 
- == Does HttpClient support NTLM authentication? ==
- 
- [http://jakarta.apache.org/commons/httpclient/ HttpClient] supports NTLMv1.
- It does not support NTLMv2 nor LMv2.
- We happen to have an NTLMv1 implementation in our code base, and we'll
- continue to support it. But we don't have the resources or the inclination
- to implement (NT)LMv2. !HttpClient is about HTTP, not NTLM.
- Besides, developing an NTLM implementation is a legal minefield we don't
- want to get into. We even had to reject a LMv2 contribution because of
- licensing issues.
- 
- 
- == Will HttpComponents support NTLM authentication? ==
- 
- We hope to make use of [http://jcifs.samba.org/ jCIFS]
- to support both NTLMv1 and LMv2 in
- [http://jakarta.apache.org/httpcomponents/ HttpComponents].
- Even they don't seem to have enough information to implement
- [http://jcifs.samba.org/src/docs/faq.html#ntlmv2 NTLMv2].
- 
- 
- == Why don't you use jCIFS to support NTLM in HttpClient? ==
- 
- [http://jcifs.samba.org/ jCIFS] is licensed under the
- [http://www.gnu.org/licenses/lgpl.html Lesser General Public License] (LGPL).
- This license is not compatible with the
- [http://www.apache.org/licenses/ Apache Licenses]
- under which all Apache Software is released.
- A lawyer of the Apache Software Foundation is currently
- investigating under which conditions Apache software is
- allowed to make use of LGPL software. Once we know the
- conditions, we'll consider dropping our own NTLM code
- in favor of using jCIFS for both !HttpClient and !HttpComponents.
- See also:
- 
-  * [http://wiki.apache.org/jakarta/Using_LGPL'd_code Jakarta Wiki: Using 
LGPL'd Code]
-  * [http://jakarta.apache.org/site/pmc/board-report-december2005.html Jakarta 
Board Report Dec 2005]
-  * [http://jakarta.apache.org/site/pmc/board-report-december2004.html Jakarta 
Board Report Dec 2004]
- 
- In the worst case scenario if we are precluded from using jCIFS directly we 
will host the development of 
- the NTLM authentication scheme outside Jakarta at the !SourceForge or similar 
site and release it under 
- LGPL as an optional plug-in.
- 
- == Could I use jCIFS to support NTLM in HttpClient? ==
- 
- Yes, you could. The legal nightmare starts only when you want to distribute 
that code. Or so I think.
- 
- 
- == Why does HttpClient require me to enter the password? IE doesn't! ==
- 
- !HttpClient is platform independent, including the NTLMv1 support.
- We have code that takes as input user name, password, and domain,
- and then authenticates the user.
- The IE feature to automatically use the credentials of the logged
- in user is Windows only. It makes use of native Windows APIs.
- 
- 
- == Why does HttpClient require me to enter the password? SUN JDK doesn't! ==
- 
- SUN has licensed the NTLM protocol from Microsoft. They have signed
- a contract, and probably a Non-Disclosure Agreement, to obtain the
- permission and necessary documentation for using NTLM.
- Even so, they have obtained the license only for the Windows platform.
- They make use of native code accessing native Windows APIs somewhere
- in their NTLM implementation.
- 
- We're in no position to match that effort. Neither will we use internal
- SUN APIs that are available only on the Windows platform. If they are
- accessible in the first place.
- 
- 
- == Could I obtain the password from Windows and give it to HttpClient? ==
- 
- No, almost surely not. The SUN JDK code that uses the current
- user's credentials for NTLM authentication does not obtain the
- password. Rather, it uses a native API to obtain a hash value
- that must be computed based on the password during NTLM authentication.
- You could analyze the SUN JDK code to see whether you can call that
- st

[Httpcomponents Wiki] Update of "FrequentlyAskedNTLMQuestions" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" 
for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/HttpComponents/FrequentlyAskedNTLMQuestions

The comment on the change is:
added info on new documentation to answer #3

New page:
#pragma section-numbers 2

= Frequently Asked Questions About NTLM =


[[TableOfContents]]


== What is NTLM? ==

NTLM is a proprietary protocol conceived by Microsoft. It can be used,
among other things, to authenticate against Microsoft HTTP servers and
proxies. There is no official, publicly available, complete documentation of 
the protocol.
Most of the information that can be found on the internet had to be
gathered through reverse engineering.
There are two versions of the NTLM protocol, commonly
referred to as NTLMv1 (version 1) and NTLMv2 (version 2).
There's also a stripped-down version of NTLMv2 called LMv2 mentioned
in the [http://jcifs.samba.org/src/docs/faq.html#ntlmv2 jCIFS FAQ].


== Does HttpClient support NTLM authentication? ==

[http://hc.apache.org/httpclient-3.x/ Commons HttpClient] supports NTLMv1.
It does not support NTLMv2 nor LMv2.
We happen to have an NTLMv1 implementation in our code base, and we'll
continue to support it. But we don't have the resources or the inclination
to implement (NT)LMv2. !HttpClient is about HTTP, not NTLM.
Besides, developing an NTLM implementation is a legal minefield we don't
want to get into. We even had to reject a LMv2 contribution because of
licensing issues.


== Will HttpComponents support NTLM authentication? ==

We hope to make use of [http://jcifs.samba.org/ jCIFS]
to support both NTLMv1 and LMv2 in
[http://hc.apache.org/ HttpComponents].
Even they don't seem to have enough information to implement
[http://jcifs.samba.org/src/docs/faq.html#ntlmv2 NTLMv2].
Since December 2007, the Samba team has
[http://news.samba.org/announcements/pfif/ access to documentation]
from Microsoft via the Protocol Freedom Information Foundation.
Maybe that will change the situation.


== Why don't you use jCIFS to support NTLM in HttpClient? ==

[http://jcifs.samba.org/ jCIFS] is licensed under the
[http://www.gnu.org/licenses/lgpl.html Lesser General Public License] (LGPL).
This license is not compatible with the
[http://www.apache.org/licenses/ Apache Licenses]
under which all Apache Software is released.
A lawyer of the Apache Software Foundation is currently
investigating under which conditions Apache software is
allowed to make use of LGPL software. Once we know the
conditions, we'll consider dropping our own NTLM code
in favor of using jCIFS for both !HttpClient and !HttpComponents.
See also:

 * [http://wiki.apache.org/jakarta/Using_LGPL'd_code Jakarta Wiki: Using LGPL'd 
Code]
 * [http://jakarta.apache.org/site/pmc/board-report-december2005.html Jakarta 
Board Report Dec 2005]
 * [http://jakarta.apache.org/site/pmc/board-report-december2004.html Jakarta 
Board Report Dec 2004]

In the worst case scenario if we are precluded from using jCIFS directly we 
will host the development of 
the NTLM authentication scheme outside of Apache at the !SourceForge or similar 
site and release it under 
LGPL as an optional plug-in.

== Could I use jCIFS to support NTLM in HttpClient? ==

Yes, you could. The legal nightmare starts only when you want to distribute 
that code. Or so I think.


== Why does HttpClient require me to enter the password? IE doesn't! ==

!HttpClient is platform independent, including the NTLMv1 support.
We have code that takes as input user name, password, and domain,
and then authenticates the user.
The IE feature to automatically use the credentials of the logged
in user is Windows only. It makes use of native Windows APIs.


== Why does HttpClient require me to enter the password? SUN JDK doesn't! ==

SUN has licensed the NTLM protocol from Microsoft. They have signed
a contract, and probably a Non-Disclosure Agreement, to obtain the
permission and necessary documentation for using NTLM.
Even so, they have obtained the license only for the Windows platform.
They make use of native code accessing native Windows APIs somewhere
in their NTLM implementation.

We're in no position to match that effort. Neither will we use internal
SUN APIs that are available only on the Windows platform. If they are
accessible in the first place.


== Could I obtain the password from Windows and give it to HttpClient? ==

No, almost surely not. The SUN JDK code that uses the current
user's credentials for NTLM authentication does not obtain the
password. Rather, it uses a native API to obtain a hash value
that must be computed based on the password during NTLM authentication.
You could analyze the SUN JDK code to see whether you can call that
step from outside. Or you implement some native code on your own to
do the same thing. Then you'd have to modify the NTLM implementation
in !HttpClient to use that native code instead of computing t

[Jakarta-httpclient Wiki] Update of "FrequentlyAskedConnectionManagementQuestions" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-httpclient
Wiki" for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/jakarta-httpclient/FrequentlyAskedConnectionManagementQuestions

--
- #pragma section-numbers 2
+ #DEPRECATED

- = Connection Management FAQ =
+ This page has been
[http://wiki.apache.org/HttpComponents/FrequentlyAskedConnectionManagementQuestions
moved]
+ to the new [http://wiki.apache.org/HttpComponents/ HttpComponents Wiki].

- This document addresses questions about connection management which
- have been raised repeatedly on the HttpClient and HttpComponents mailing
lists.
-
-
- [[TableOfContents]]
-
-
- ---
- == Connections in TIME_WAIT State ==
-
- After running your HTTP application, you use the [http://www.netstat.net/
netstat] command
- and detect a lot of connections in state '''TIME_WAIT'''.
- Now you wonder why these connections are not cleaned up.
-
- === What is the TIME_WAIT State? ===
-
- The TIME_WAIT state is a protection mechanism in TCP.
- The side that closes a socket connection orderly will keep the connection
- in state TIME_WAIT for some time, typically between 1 and 4 minutes.
- This happens ''after'' the connection is closed. It does ''not'' indicate a
cleanup problem.
- The TIME_WAIT state protects against loss of data and data corruption.
- It is there to help you. For technical details, have a look at the
-
[http://www.softlab.ntua.gr/facilities/documentation/unix/unix-socket-faq/unix-socket-faq-2.html#ss2.7
Unix Socket FAQ, section 2.7].
-
- === Some Connections Go To TIME_WAIT, Others Not ===
-
- If a connection is orderly closed by your application, it will go to the
TIME_WAIT state.
- If a connection is orderly closed by the server, the server keeps it in
TIME_WAIT and your client doesn't.
- If a connection is reset or otherwise dropped by your application in a
non-orderly fashion,
- it will not go to TIME_WAIT.
-
- Unfortunately, it will not always be obvious to you whether a connection is
closed orderly or not.
- This is because connections are pooled and kept open for re-use by default.
- !HttpClient 3.x, !HttpClient 4, and also the standard Java HttpURLConnection
do that for you.
- Most applications will simply execute requests, then read from the response
stream,
- and finally close that stream.
- [[BR]]
- Closing the response stream is ''not'' the same thing as closing the
connection!
- Closing the response stream returns the connection to the pool, but it will
be kept open if possible.
- This saves a lot of time if you send another request to the same host within
a few seconds, or even minutes.
-
- Connection pools have a limited number of connections.
- A pool may have 5 connections, or 100, or maybe only 1.
- When you send a request to a host, and there is no open connection to that
host in the pool,
- a new connection needs to be opened. But if the pool is already full,
- an open connection has to be closed before a new one can be opened.
- In this case, the old connection will be closed orderly and go to the
TIME_WAIT state.
- [[BR]]
- When your application exits and the JVM terminates, the open connections in
the pools
- will ''not'' be closed orderly. They are reset or cancelled, without going to
TIME_WAIT.
- To avoid this, you should call the {{{shutdown}}} method of the connection
pools your
- application is using before exiting.
- The standard Java HttpURLConnection has no public method to shutdown it's
connection pool.
-
- === Running Out Of Ports ===
-
- Some applications open and orderly close a lot of connections within a short
time,
- for example when load-testing a server. A connection in state TIME_WAIT will
prevent
- that port number from being re-used for another connection. That is not an
error,
- it is the purpose of TIME_WAIT.
-
- TCP is configured at the operating system level, not through Java.
- Your first action should be to increase the number of ephemeral ports on the
machine.
- Windows in particular has a rather low default for the ephemeral ports.
- The [http://www.performancewiki.com/ PerformanceWiki] has tuning tips for the
- common operating systems, have a look at the respective Network section.
- [[BR]]
- Only if increasing the number of ephemeral ports does not solve your problem,
- you should consider decreasing the duration of the TIME_WAIT state.
- You probably have to reduce the maximum lifetime of IP packets, as the
duration
- of TIME_WAIT is typically twice that timespan to allow for a round-trip delay.
- Be aware that this will affect ''all'' applications running on the machine.
- Don't ask us how to do it, we're not the experts for network tuning.
-
- There are some ways to deal with the problem at the application level.
- One way is to send a "Connection: close" header with each request.
- That wil

[Httpcomponents Wiki] Update of "FrequentlyAskedConnectionManagementQuestions" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki"
for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/HttpComponents/FrequentlyAskedConnectionManagementQuestions

New page:
#pragma section-numbers 2

= Connection Management FAQ =

This document addresses questions about connection management which
have been raised repeatedly on the !HttpClient and !HttpComponents
[http://hc.apache.org/mail.html mailing lists].

[[TableOfContents]]

---
== Connections in TIME_WAIT State ==

After running your HTTP application, you use the [http://www.netstat.net/
netstat] command
and detect a lot of connections in state '''TIME_WAIT'''.
Now you wonder why these connections are not cleaned up.

=== What is the TIME_WAIT State? ===

The TIME_WAIT state is a protection mechanism in TCP.
The side that closes a socket connection orderly will keep the connection
in state TIME_WAIT for some time, typically between 1 and 4 minutes.
This happens ''after'' the connection is closed. It does ''not'' indicate a
cleanup problem.
The TIME_WAIT state protects against loss of data and data corruption.
It is there to help you. For technical details, have a look at the
[http://www.softlab.ntua.gr/facilities/documentation/unix/unix-socket-faq/unix-socket-faq-2.html#ss2.7
Unix Socket FAQ, section 2.7].

=== Some Connections Go To TIME_WAIT, Others Not ===

If a connection is orderly closed by your application, it will go to the
TIME_WAIT state.
If a connection is orderly closed by the server, the server keeps it in
TIME_WAIT and your client doesn't.
If a connection is reset or otherwise dropped by your application in a
non-orderly fashion,
it will not go to TIME_WAIT.

Unfortunately, it will not always be obvious to you whether a connection is
closed orderly or not.
This is because connections are pooled and kept open for re-use by default.
!HttpClient 3.x, !HttpClient 4, and also the standard Java HttpURLConnection do
that for you.
Most applications will simply execute requests, then read from the response
stream,
and finally close that stream.
[[BR]]
Closing the response stream is ''not'' the same thing as closing the connection!
Closing the response stream returns the connection to the pool, but it will be
kept open if possible.
This saves a lot of time if you send another request to the same host within a
few seconds, or even minutes.

Connection pools have a limited number of connections.
A pool may have 5 connections, or 100, or maybe only 1.
When you send a request to a host, and there is no open connection to that host
in the pool,
a new connection needs to be opened. But if the pool is already full,
an open connection has to be closed before a new one can be opened.
In this case, the old connection will be closed orderly and go to the TIME_WAIT
state.
[[BR]]
When your application exits and the JVM terminates, the open connections in the
pools
will ''not'' be closed orderly. They are reset or cancelled, without going to
TIME_WAIT.
To avoid this, you should call the {{{shutdown}}} method of the connection
pools your
application is using before exiting.
The standard Java HttpURLConnection has no public method to shutdown it's
connection pool.

=== Running Out Of Ports ===

Some applications open and orderly close a lot of connections within a short
time,
for example when load-testing a server. A connection in state TIME_WAIT will
prevent
that port number from being re-used for another connection. That is not an
error,
it is the purpose of TIME_WAIT.

TCP is configured at the operating system level, not through Java.
Your first action should be to increase the number of ephemeral ports on the
machine.
Windows in particular has a rather low default for the ephemeral ports.
The [http://www.performancewiki.com/ PerformanceWiki] has tuning tips for the
common operating systems, have a look at the respective Network section.
[[BR]]
Only if increasing the number of ephemeral ports does not solve your problem,
you should consider decreasing the duration of the TIME_WAIT state.
You probably have to reduce the maximum lifetime of IP packets, as the duration
of TIME_WAIT is typically twice that timespan to allow for a round-trip delay.
Be aware that this will affect ''all'' applications running on the machine.
Don't ask us how to do it, we're not the experts for network tuning.

There are some ways to deal with the problem at the application level.
One way is to send a "Connection: close" header with each request.
That will tell the server to close the connection, so it goes to TIME_WAIT on
the other side.
Of course this also disables the keep-alive feature of connection pooling
and thereby degrades performance. If you are running load tests against a
server,
the untypical behavior of your application may distort the test results.
[[BR]
Another way is to not orderly close connections. There is a trick to set
SO_LINGER to a

[Jakarta-httpclient Wiki] Update of "FrequentlyAskedApplicationDesignQuestions" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-httpclient 
Wiki" for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/jakarta-httpclient/FrequentlyAskedApplicationDesignQuestions

--
- #pragma section-numbers 2
+ #DEPRECATED
  
- = Application Design FAQ =
+ This page has been 
[http://wiki.apache.org/HttpComponents/FrequentlyAskedApplicationDesignQuestions
 moved]
+ to the new [http://wiki.apache.org/HttpComponents/ HttpComponents Wiki].
  
- This document addresses questions about application design which
- have been raised repeatedly on the HttpClient and HttpComponents mailing 
lists.
- As it addresses design issues rather than API or other HttpClient or
- HttpComponents specific problems, much of the information presented
- is equally applicable for HttpURLConnection or non-Java APIs.
- 
- If you are just getting your feet wet and want to understand the basics
- of client HTTP programming rather than read about application design 
alternatives,
- check out our [wiki:Self:ForAbsoluteBeginners primer].
- 
- 
- [[TableOfContents]]
- 
- 
- ---
- == Sending Parameters and Uploading Files  ==
- 
- A question that is asked on a regular basis is:
- 
-  ''How do I upload a file along with some parameters?''
- 
- This section presents different ways to upload parameters, files, and both.
- It assumes that you are implementing both a client application and
- a server application to which the client application connects.
- The client application might be a Java program using HttpClient,
- while the server application is assumed to be a
- 
[http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/http/HttpServlet.html
 Servlet].
- 
- Parameters are name/value pairs, where both name and value are strings.
- Names should always be in US-ASCII, values may use other character
- encodings, depending on the technique used for sending the parameters.
- Files or rather file parameters are name/value pairs, where the name is
- a string and the value is binary data read from a file. Binary values
- from other sources can be handled similar to files from a design perspective,
- though the details of the API will vary.
- 
- 
- === GET with Query ===
- 
- The simplest way to transfer parameters to the server is the
- query string of the URL. That's the part after the question mark,
- for example in:
- 
-  http:''//my.server.name/my/servlet'''?param1=value1¶m2=value2'''
- 
- Query strings can be used with any HTTP method, but they are most
- frequently used with the GET method. A query string is also the
- only way to send parameters with a GET method.
- (Unless your application encodes parameters into the URL path.)
- 
- The names and values of a query string must be URL-escaped. Each space 
character needs to
- be replaced by a + character. Reserved characters like = & % + : / need to be
- URL-escaped (%xx sequences) with their byte representation (see below).
- URL-escaping is automatically handled for example by the 
[http://java.sun.com/j2se/1.5.0/docs/api/java/net/URI.html#URI(java.lang.String,%20java.lang.String,%20java.lang.String,%20int,%20java.lang.String,%20java.lang.String,%20java.lang.String)
 java.net.URI]
- and 
[http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/URI.html#setRawQuery(char%5b%5d)
 org.apache.commons.httpclient.URI] classes.
- 
- HTTP Request lines and thus query strings are confined to the ASCII character 
encoding. Only ASCII names/values
- can reliably be transferred in a query string. However it is possible to use 
a non-ASCII character encoding by
- URL-escaping the characters. Character encodings (like UTF-8, ISO-8859-1; and 
unlike EBCDIC) whose lower 7-bit are 
- compatible with ASCII only need to escape the non-ASCII characters. The 
character encoding used to create and 
- interprete the % escape sequences must be the same on the server and on the 
client. It is common practice to
- agree on UTF-8. But it is more a recommendation than a standard and must be 
verified in individual cases. 
- To avoid problems it is strongly discouraged to send non-ASCII values in the 
query string.
- 
- Depending on the encoding the following characters are character encoded and 
URL-escaped as follows:
- || char || ASCII || ISO-8859-1 || UTF-8  || EBCDIC ||
- || A|| A || A  || A  || %E1||
- || Ã¤|| N/A   || %E4|| %C3%A4 || N/A||
- || &|| %26   || %26|| %26|| %70||
- 
- On the server, name/value pairs sent in a query string are available
- as parameters of the 
[http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/ServletRequest.html#getParameter(java.lang.String)
 ServletRequest].
- %xx escape sequences and + characters are automatically decoded by the 
Servlet API.
- If non-ASCII values are sent in the query string, the outcome dep

[Httpcomponents Wiki] Update of "FrequentlyAskedApplicationDesignQuestions" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" 
for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/HttpComponents/FrequentlyAskedApplicationDesignQuestions

New page:
#pragma section-numbers 2

= Application Design FAQ =

This document addresses questions about application design which
have been raised repeatedly on the !HttpClient and !HttpComponents
[http://hc.apache.org/mail.html mailing lists].
As it addresses design issues rather than API or other !HttpClient or
HttpComponents specific problems, much of the information presented
is equally applicable for HttpURLConnection or non-Java APIs.

If you are just getting your feet wet and want to understand the basics
of client HTTP programming rather than read about application design 
alternatives,
check out our [wiki:Self:ForAbsoluteBeginners primer].


[[TableOfContents]]


---
== Sending Parameters and Uploading Files  ==

A question that is asked on a regular basis is:

 ''How do I upload a file along with some parameters?''

This section presents different ways to upload parameters, files, and both.
It assumes that you are implementing both a client application and
a server application to which the client application connects.
The client application might be a Java program using HttpClient,
while the server application is assumed to be a
[http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/http/HttpServlet.html
 Servlet].

Parameters are name/value pairs, where both name and value are strings.
Names should always be in US-ASCII, values may use other character
encodings, depending on the technique used for sending the parameters.
Files or rather file parameters are name/value pairs, where the name is
a string and the value is binary data read from a file. Binary values
from other sources can be handled similar to files from a design perspective,
though the details of the API will vary.


=== GET with Query ===

The simplest way to transfer parameters to the server is the
query string of the URL. That's the part after the question mark,
for example in:

 http:''//my.server.name/my/servlet'''?param1=value1¶m2=value2'''

Query strings can be used with any HTTP method, but they are most
frequently used with the GET method. A query string is also the
only way to send parameters with a GET method.
(Unless your application encodes parameters into the URL path.)

The names and values of a query string must be URL-escaped. Each space 
character needs to
be replaced by a + character. Reserved characters like = & % + : / need to be
URL-escaped (%xx sequences) with their byte representation (see below).
URL-escaping is automatically handled for example by the 
[http://java.sun.com/j2se/1.5.0/docs/api/java/net/URI.html#URI(java.lang.String,%20java.lang.String,%20java.lang.String,%20int,%20java.lang.String,%20java.lang.String,%20java.lang.String)
 java.net.URI]
and 
[http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/URI.html#setRawQuery(char%5b%5d)
 org.apache.commons.httpclient.URI] classes.

HTTP Request lines and thus query strings are confined to the ASCII character 
encoding. Only ASCII names/values
can reliably be transferred in a query string. However it is possible to use a 
non-ASCII character encoding by
URL-escaping the characters. Character encodings (like UTF-8, ISO-8859-1; and 
unlike EBCDIC) whose lower 7-bit are 
compatible with ASCII only need to escape the non-ASCII characters. The 
character encoding used to create and 
interprete the % escape sequences must be the same on the server and on the 
client. It is common practice to
agree on UTF-8. But it is more a recommendation than a standard and must be 
verified in individual cases. 
To avoid problems it is strongly discouraged to send non-ASCII values in the 
query string.

Depending on the encoding the following characters are character encoded and 
URL-escaped as follows:
|| char || ASCII || ISO-8859-1 || UTF-8  || EBCDIC ||
|| A|| A || A  || A  || %E1||
|| Ã¤|| N/A   || %E4|| %C3%A4 || N/A||
|| &|| %26   || %26|| %26|| %70||

On the server, name/value pairs sent in a query string are available
as parameters of the 
[http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/ServletRequest.html#getParameter(java.lang.String)
 ServletRequest].
%xx escape sequences and + characters are automatically decoded by the Servlet 
API.
If non-ASCII values are sent in the query string, the outcome depends
on the implementation of the Servlet API, the Content-Type header and possibly 
also on
configuration parameters, such as the JVM default character set.
That's why it is strongly discouraged to send non-ASCII values
in the query string.


=== POST with URL-encoded Form Data ===

Unlike the GET method, a POST method has a message body or entity
which can hold any kind of binary or non-binary

[Httpcomponents Wiki] Update of "FrontPage" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" 
for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/HttpComponents/FrontPage

The comment on the change is:
pointing FAQs to the new wiki

--
  User information is meant for people using our components or Commons 
!HttpClient 3.1,
  or for people considering to use them.
  For starters, we have a list of HttpClientPowered applications that use 
!HttpClient.
+ Then there is documentation and several FAQs in this list:
+ 
+1. [wiki:Self:ForAbsoluteBeginners Client HTTP Programming Primer] - How 
to simulate HTML form submission
+1. [wiki:Self:GuidedTourOfHttpCore Guided Tour of HttpCore] - Overview 
documentation for HttpComponents Core
+1. [wiki:Self:FrequentlyAskedApplicationDesignQuestions Application Design 
FAQ]
+1. [wiki:Self:FrequentlyAskedConnectionManagementQuestions Connection 
Management FAQ] - What is TIME_WAIT etc
+1. [wiki:Self:FrequentlyAskedNTLMQuestions NTLM FAQ]
+ 
+ We also keep a [http://hc.apache.org/user-docs.html user documentation index] 
on our website.
+ It points to !JavaDocs and example code not linked from this wiki.
+ 
  If you are considering the old codebase versus the new components, the
  [http://wiki.apache.org/jakarta-httpclient/HttpClient3vsHttpClient4vsHttpCore 
benchmark results]
  could be of use.
- Then there is documentation and several FAQs in the list below.
- We also keep a [http://hc.apache.org/user-docs.html user documentation index] 
on our website.
+ [[BR]]
+ If you are stuck with a very old JVM and have to use HTTPS, you need a
+ [http://wiki.apache.org/jakarta-httpclient/AlternativeJSSE JSSE 
Implementation].
  
-1. [wiki:Self:ForAbsoluteBeginners Client HTTP Programming Primer]
-1. [wiki:Self:GuidedTourOfHttpCore Guided Tour of HttpCore] - Overview 
documentation for HttpComponents Core
-1. 
[http://wiki.apache.org/jakarta-httpclient/FrequentlyAskedApplicationDesignQuestions
 Application Design FAQ]
-1. 
[http://wiki.apache.org/jakarta-httpclient/FrequentlyAskedConnectionManagementQuestions
 Connection Management FAQ] - What is TIME_WAIT etc
-1. [http://wiki.apache.org/jakarta-httpclient/AlternativeJSSE JSSE 
Implementations] - Links to JSSE implementations for HTTPS connectivity
-1. [http://wiki.apache.org/jakarta-httpclient/FrequentlyAskedNTLMQuestions 
NTLM FAQ]
  
  
  == Developer Information ==

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: unable to encode reserved characters using java.net.URI multi-arg constructors

Oleg Kalnichevski wrote:
> On Sat, 2008-01-19 at 09:33 -0800, Sam Berlin wrote:
>> It almost certainly would work, however HttpClient would then be
>> broken (as far as URI parsing goes) for everyone else.  As others have
>> pointed out (and as Tim explained to me in sad detail), URI is just
>> basically broken when it comes to using it with the multi-arg
>> constructors.  It's flat-out impossible to recreate a URI with the
>> multi-arg constructors and have it point to the correct resource.
> 
> What would be your suggestion on dealing with the issue? Is there anyway
> we could avoid rewriting the whole URI class and leverage functionality
> already available in the JRE?  

I don't know by heart where we are creating URIs. If path escaping
is the problem, maybe we can use some workaround like:

URI base = new URI(scheme, hostport, null);
URI full = base.resolve(pathonly); // maps to single-arg constructor

cheers,
  Roland

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Httpcomponents Wiki] Update of "FrontPage" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" 
for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/HttpComponents/FrontPage

The comment on the change is:
split the Table Of Contents into multiple sections

--
  
  If you're new to wikis you might want to read HelpForBeginners to get an idea 
of how they work and how you can contribute.
  
- == Table of Contents ==
  
-  * Users
-1. HttpClientPowered - A list of applications that use !HttpClient
+ == User Information ==
+ 
+ User information is meant for people using our components or Commons 
!HttpClient 3.1,
+ or for people considering to use them.
+ For starters, we have a list of HttpClientPowered applications that use 
!HttpClient.
+ If you are considering the old codebase versus the new components, the
+ [http://wiki.apache.org/jakarta-httpclient/HttpClient3vsHttpClient4vsHttpCore 
benchmark results]
+ could be of use.
+ Then there is documentation and several FAQs in the list below.
+ We also keep a [http://hc.apache.org/user-docs.html user documentation index] 
on our website.
+ 
 1. [wiki:Self:ForAbsoluteBeginners Client HTTP Programming Primer]
 1. [wiki:Self:GuidedTourOfHttpCore Guided Tour of HttpCore] - Overview 
documentation for HttpComponents Core
 1. 
[http://wiki.apache.org/jakarta-httpclient/FrequentlyAskedApplicationDesignQuestions
 Application Design FAQ]
@@ -30, +38 @@

 1. [http://wiki.apache.org/jakarta-httpclient/AlternativeJSSE JSSE 
Implementations] - Links to JSSE implementations for HTTPS connectivity
 1. [http://wiki.apache.org/jakarta-httpclient/FrequentlyAskedNTLMQuestions 
NTLM FAQ]
  
-  * Development
+ 
+ == Developer Information ==
+ 
+ Developer information is meant for people working on our project codebase,
+ including the Java source code as well as the sources for generating our 
website.
+ 
 1. http://wiki.apache.org/jakarta-httpclient/WebSite - How to update and 
deploy the HttpComponents website
 1. [http://wiki.apache.org/jakarta-httpclient/HttpClientReleaseProcess 
Commons HttpClient 3.x release process] - How to cut and publish a release of 
Commons !HttpClient 3.x
 1. 
[http://wiki.apache.org/jakarta-httpclient/HttpComponentsCoreReleaseProcess 
HttpComponents Core release process] - How to cut and publish a release of 
!HttpComponents Core
@@ -39, +52 @@

 1. http://wiki.apache.org/jakarta-httpclient/HttpComponentsAndOSGi - 
Generating OSGi bundles for our modules
 1. ReferenceMaterials - Links to relevant standards
  
-  * Benchmarks
-1. 
http://wiki.apache.org/jakarta-httpclient/HttpClient3vsHttpClient4vsHttpCore - 
!HttpClient 3.x vs !HttpClient 4.x vs !HttpCore 4.x performance benchmarks
  
-  * Formalities
+ == PMC Information ==
+ 
 1. [http://wiki.apache.org/jakarta-httpclient/BoardReports Board Reports]
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Httpcomponents Wiki] Update of "HttpComponents" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" 
for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/HttpComponents/HttpComponents

The comment on the change is:
terminology details

--
  
  The [http://jakarta.apache.org/httpcomponents/ HttpComponents] are the 
successor to
  Commons !HttpClient, version 3. Incorporating the lessons learned from 
Commons !HttpClient,
- they provide a modular set of identifiable units with specific 
responsibilities for
+ they provide a modular set of functional units with specific responsibilities 
for
  various aspects of HTTP based communication.
  
- Below, you will find a list of the informal units with a short description.
+ Below, you will find a list of the functional units with a short description.
  But first you should read about the different levels of grouping used 
throughout the project.
  This is essential if you don't want to get confused by discussions on the 
developer mailing list.
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Jakarta-httpclient Wiki] Update of "GuidedTourOfHttpCore" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-httpclient 
Wiki" for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/jakarta-httpclient/GuidedTourOfHttpCore

--
+ #DEPRECATED
- ## pragma section-numbers 2
- = A Guided Tour of HttpCore (module-main) =
  
+ This page has been 
[http://wiki.apache.org/HttpComponents/GuidedTourOfHttpCore moved]
+ to the new [http://wiki.apache.org/HttpComponents/ HttpComponents Wiki].
- 
- [[TableOfContents]]
- 
  
- == Welcome ==
- 
- Welcome, visitors, to this guided tour of [wiki:Self:HttpComponents HttpCore].
- I am your tour guide.
- If you could please come a little closer and gather around me,
- so I don't have to shout? Thank you, that's much better.
- I'm about to give you a short introduction, and then we'll visit
- some interesting places in !HttpCore so you can see how it works.
- Whenever you've got a question, feel free to ask.
- That's what I'm here for, to answer your questions.
- 
- As you probably know, HTTP is a protocol for exchanging messages
- between a client and a server. It's in widespread use, and it
- typically is running on top of plain TCP/IP or secure TLS/SSL sockets.
- [[BR]]
- Here at [http://www.apache.org/ Apache], there is an implementation
- of the client side of that protocol called the Commons HttpClient.
- Informally, we also call it "the 3.x codebase" or simply "the old code".
- It proved quite useful to a lot of people, but the old code has severe
- limitations in it's design.
- For example, there is a class called {{{HttpMethodBase}}}.
- It represents a request and a response at the same time,
- and it also implements logic for processing both.
- This kind of design where different things are crammed together
- in a single place makes it really hard to maintain or extend the code.
- 
- Therefore we started a new successor project called HttpComponents.
- Based on the experience gained with the old code, it implements the
- HTTP protocol with a new approach. Above all, there are several modules
- dealing with different aspects of the big problem.
- As you can gather from it's name, the !HttpCore module is at the
- very heart of this effort. It defines stuff on which all the other
- modules depend and rely.
- [[BR]]
- !HttpCore deals with representation of HTTP messages, and
- with transport logic for sending and receiving those messages.
- It also defines a kind of framework infrastructure so other
- modules can plug in functionality.
- Unlike the old code, !HttpCore is not specific to the client side
- of HTTP communication, it can also be used for the server side.
- And because it is so fundamentally different from it's predecessor,
- we put all the code into an all-new package hierarchy so you
- don't confuse them.
- 
-  '''Q:''' I have a question.
-  [[BR]]
-  '''A:''' Yes, please? What would you like to ask?
-  [[BR]]
-  '''Q:'''
-  If it is in a new package hierarchy, applications written
-  for the old code will not be able to use the new one?
-  [[BR]]
-  '''A:'''
-  Yes, that is correct. Because the old code was limited in it's design,
-  we had to change the API. Applications have to be rewritten to
-  make use of the new code. There was no way to avoid this.
-  The all-new package names at least make sure that both old and new code
-  can be used in the same environment, for example a Servlet engine,
-  without interference.
- 
- Now, if you would like to follow me to the main hall...
- it's called package {{{org.apache.http}}}.
- You may want to keep the
- [http://hc.apache.org/httpcomponents-core/httpcore/apidocs/index.html 
JavaDocs]
- at hand, that will make it easier for you to follow my explanations.
- 
- 
- 
- == Messages ==
- 
- The first problem we had to deal with is the representation of messages.
- If you don't know how to represent a message, you can't send or receive it,
- right?
- So here we have a set of interfaces for the building blocks of an HTTP 
message.
- There's the {{{RequestLine}}} for a request and the
- {{{StatusLine}}} for a response, both containing a {{{ProtocolVersion}}}.
- The latter is so elementary that we made it a class instead of an interface,
- and of course we have the {{{HttpVersion}}} derived from it.
- Then we have a {{{Header}}} with name and value, where the value
- can have multiple {{{HeaderElement}}}s. And finally there is the
- message body, the {{{HttpEntity}}}.
- 
-  '''Q:'''
-  {{{HttpVersion}}} derived from {{{ProtocolVersion}}}?
-  Wouldn't the protocol always be HTTP in HttpCore?
-  [[BR]]
-  '''A:'''
-  Not quite. There is at least one other protocol,
-  the Session Initiation Protocol SIP,
-  which has a message format identical to that of HTTP.
-  Only the protocol name and version differs.
-  Since it's so similar, we tried to keep the door open.
-  [[BR]]
-  '''Q:''' That makes sense.
- 
- So, out of the

[Jakarta-httpclient Wiki] Update of "HttpComponents" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-httpclient 
Wiki" for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/jakarta-httpclient/HttpComponents

--
- = HTTP Components =
+ #DEPRECATED
  
- The [http://jakarta.apache.org/httpcomponents/ HttpComponents] are the 
successor to HttpClient, version 3.
- Incorporating the lessons learned from !HttpClient, they provide a modular 
set of identifiable units with specific responsibilities for various aspects of 
HTTP based communication.
+ This page has been [http://wiki.apache.org/HttpComponents/HttpComponents 
moved]
+ to the new [http://wiki.apache.org/HttpComponents/ HttpComponents Wiki].
  
- Below, you will find a list of the identifiable units with a short 
description.
- But first you should read about the different levels of grouping used 
throughout the project.
- This is essential if you don't want to get confused by discussions on the 
developer mailing list.
- 
- 
- == Levels of Grouping ==
- 
- ||Component||
- ||Module||
- ||''unit'' (informal)||
- 
- The Component is the coarsest level of grouping.
- Components have their own release cycle, and each release
- will update everything that is in the component.
- Components are separate projects in JIRA, and they have their own Subversion 
subtree in
- [http://svn.apache.org/repos/asf/httpcomponents/ .../httpcomponents].
- [[BR]]
- The second level of grouping is the Module.
- A component holds one or more modules, where each module is
- a distinct compilation unit and will be packaged in a separate JAR.
- All modules of a component are updated with each release
- of the component.
- In Subversion, each module has it's own subtree in the respective
- component tree. Module subtrees are labelled {{{module-}}}.
- In the JIRA project for the component, you will find
- a JIRA component for each module.
- 
- While component and module are groupings that affect the
- layout of the Subversion repository for HttpComponents,
- the finest level of grouping is of an informal nature.
- It doesn't even have an official term.
- We started by calling these informal units ''components'',
- but that is also used for the release units now.
- In some cases, the modules correspond to informal units.
- But there are other cases where different informal units are
- joined in one module, distinguished only by Java package names.
- You are likely to find a JIRA component defined for an informal unit,
- to simplify our issue tracking.
- It is still up for discussion which of the informal units should
- become modules. It does require some effort to create a module,
- and in the early stages of development the code may not be separated
- sufficiently to put it into a distinct compilation unit.
- 
- 
- In discussions on the mailing list, the same name is used to refer to 
component, module, or informal unit.
- For example, !HttpCore or http-core is an informal unit, a distinct module, 
and a component that includes other modules.
- On the other hand, !HttpClient or http-client is an informal unit and a 
component,
- but shares a module with other informal units.
- The context will usually disambiguate the meaning, otherwise just ask.
- When referring specifically to a module, its label can be used.
- The module !HttpCore is called {{{module-main}}} in component !HttpCore,
- whereas {{{module-client}}} in component !HttpClient is shared between
- several informal units, including !HttpClient.
- 
- 
- == List of Informal Units ==
- 
- === HttpCore ===
- 
- {{{module-main}}} in component !HttpCore
- 
- The core defines abstractions and provides default implementations for
- HTTP related stuff like messages, headers, entities and connections.
- It also includes a protocol execution framework based on interceptors.
- !HttpCore has no external dependencies. We keep the source compatible
- with Java 1.3, but the released binaries will only be tested against
- Java 5.0. If you plan to use it in a Java 1.3 environment, you should
- build your own binaries from the source.
- 
- 
- === HttpNIO, HttpNIOSSL ===
- 
- {{{module-nio}}} in component !HttpCore, depends on {{{module-main}}}
- 
- The NIO modules add support for non-blocking Java NIO to the core.
- Up to and including the release alpha6, NIO support for SSL was in
- a separate module because of it's dependency on Java 5. After we upgraded
- the Java requirement to 5.0 for everything except {{{module-main}}},
- HttpNIOSSL was merged into HttpNIO.
- 
- 
- === HttpAuth ===
- 
- {{{module-client}}} in component !HttpClient, depends on {{{module-main}}}
- [[BR]]
- External dependencies: commons-codec
- 
- This informal unit provides support for HTTP authentication mechanisms
- like BASIC and DIGEST.
- 
- 
- === HttpCookie ===
- 
- {{{module-client}}} in component !HttpClient, depends on {{{module-main}}}
- 
- This informal unit

[Httpcomponents Wiki] Update of "FrontPage" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" 
for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/HttpComponents/FrontPage

--
   * Users
 1. HttpClientPowered - A list of applications that use !HttpClient
 1. [wiki:Self:ForAbsoluteBeginners Client HTTP Programming Primer]
-1. [http://wiki.apache.org/jakarta-httpclient/GuidedTourOfHttpCore Guided 
Tour of HttpCore] - Overview documentation for HttpComponents Core
+1. [wiki:Self:GuidedTourOfHttpCore Guided Tour of HttpCore] - Overview 
documentation for HttpComponents Core
 1. 
[http://wiki.apache.org/jakarta-httpclient/FrequentlyAskedApplicationDesignQuestions
 Application Design FAQ]
 1. 
[http://wiki.apache.org/jakarta-httpclient/FrequentlyAskedConnectionManagementQuestions
 Connection Management FAQ] - What is TIME_WAIT etc
 1. [http://wiki.apache.org/jakarta-httpclient/AlternativeJSSE JSSE 
Implementations] - Links to JSSE implementations for HTTPS connectivity
@@ -37, +37 @@

 1. 
http://wiki.apache.org/jakarta-httpclient/HttpClientApiJavadocGuidelines - API 
Java''Doc guidelines for !HttpComponents
 1. http://wiki.apache.org/jakarta-httpclient/ConnectionManagementDesign - 
Design considerations for connection management in !HttpComponents
 1. http://wiki.apache.org/jakarta-httpclient/HttpComponentsAndOSGi - 
Generating OSGi bundles for our modules
-1. http://wiki.apache.org/jakarta-httpclient/ReferenceMaterials - Links to 
relevant standards
+1. ReferenceMaterials - Links to relevant standards
  
   * Benchmarks
 1. 
http://wiki.apache.org/jakarta-httpclient/HttpClient3vsHttpClient4vsHttpCore - 
!HttpClient 3.x vs !HttpClient 4.x vs !HttpCore 4.x performance benchmarks

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Httpcomponents Wiki] Update of "HttpAsync" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" 
for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/HttpComponents/HttpAsync

New page:
#REDIRECT HttpComponents

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Httpcomponents Wiki] Update of "HttpConn" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" 
for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/HttpComponents/HttpConn

New page:
#REDIRECT HttpComponents

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Httpcomponents Wiki] Update of "HttpCookie" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" 
for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/HttpComponents/HttpCookie

New page:
#REDIRECT HttpComponents

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Httpcomponents Wiki] Update of "HttpAuth" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" 
for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/HttpComponents/HttpAuth

New page:
#REDIRECT HttpComponents

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Httpcomponents Wiki] Update of "HttpNIOSSL" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" 
for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/HttpComponents/HttpNIOSSL

New page:
#REDIRECT HttpComponents

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Httpcomponents Wiki] Update of "HttpNIO" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" 
for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/HttpComponents/HttpNIO

New page:
#REDIRECT HttpComponents

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Httpcomponents Wiki] Update of "HttpCore" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" 
for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/HttpComponents/HttpCore

New page:
#REDIRECT HttpComponents

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Httpcomponents Wiki] Update of "HttpClient" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" 
for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/HttpComponents/HttpClient

New page:
#REDIRECT HttpComponents

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Httpcomponents Wiki] Update of "HttpComponents" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" 
for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/HttpComponents/HttpComponents

New page:
= HTTP Components =

The [http://jakarta.apache.org/httpcomponents/ HttpComponents] are the 
successor to
Commons !HttpClient, version 3. Incorporating the lessons learned from Commons 
!HttpClient,
they provide a modular set of identifiable units with specific responsibilities 
for
various aspects of HTTP based communication.

Below, you will find a list of the informal units with a short description.
But first you should read about the different levels of grouping used 
throughout the project.
This is essential if you don't want to get confused by discussions on the 
developer mailing list.


== Levels of Grouping ==

||Component||
||Module||
||''unit'' (informal)||

The Component is the coarsest level of grouping.
Components have their own release cycle, and each release
will update everything that is in the component.
Components are separate projects in JIRA, and they have their own Subversion 
subtree in
[http://svn.apache.org/repos/asf/httpcomponents/ .../httpcomponents].
[[BR]]
The second level of grouping is the Module.
A component holds one or more modules, where each module is
a distinct compilation unit and will be packaged in a separate JAR.
All modules of a component are updated with each release
of the component.
In Subversion, each module has it's own subtree in the respective
component tree. Module subtrees are labelled {{{module-}}}.
In the JIRA project for the component, you will find
a JIRA component for each module.

While component and module are groupings that affect the
layout of the Subversion repository for HttpComponents,
the finest level of grouping is of an informal nature.
It doesn't even have an official term.
We started by calling these informal units ''components'',
but that is also used for the release units now.
In some cases, the modules correspond to informal units.
But there are other cases where different informal units are
joined in one module, distinguished only by Java package names.
You are likely to find a JIRA component defined for an informal unit,
to simplify our issue tracking.
It is still up for discussion which of the informal units should
become modules. It does require some effort to create a module,
and in the early stages of development the code may not be separated
sufficiently to put it into a distinct compilation unit.


In discussions on the mailing list, the same name is used to refer to 
component, module, or informal unit.
For example, !HttpCore or http-core is an informal unit, a distinct module, and 
a component that includes other modules.
On the other hand, !HttpClient or http-client is an informal unit and a 
component,
but shares a module with other informal units.
The context will usually disambiguate the meaning, otherwise just ask.
When referring specifically to a module, its label can be used.
The module !HttpCore is called {{{module-main}}} in component !HttpCore,
whereas {{{module-client}}} in component !HttpClient is shared between
several informal units, including !HttpClient.


== List of Informal Units ==

=== HttpCore ===

{{{module-main}}} in component !HttpCore

The core defines abstractions and provides default implementations for
HTTP related stuff like messages, headers, entities and connections.
It also includes a protocol execution framework based on interceptors.
!HttpCore has no external dependencies. We keep the source compatible
with Java 1.3, but the released binaries will only be tested against
Java 5.0. If you plan to use it in a Java 1.3 environment, you should
build your own binaries from the source.


=== HttpNIO, HttpNIOSSL ===

{{{module-nio}}} in component !HttpCore, depends on {{{module-main}}}

The NIO modules add support for non-blocking Java NIO to the core.
Up to and including the release alpha6, NIO support for SSL was in
a separate module because of it's dependency on Java 5. After we upgraded
the Java requirement to 5.0 for everything except {{{module-main}}},
HttpNIOSSL was merged into HttpNIO.


=== HttpAuth ===

{{{module-client}}} in component !HttpClient, depends on {{{module-main}}}
[[BR]]
External dependencies: commons-codec

This informal unit provides support for HTTP authentication mechanisms
like BASIC and DIGEST.


=== HttpCookie ===

{{{module-client}}} in component !HttpClient, depends on {{{module-main}}}

This informal unit provides support for HTTP cookies in various flavors.


=== HttpConn ===

{{{module-client}}} in component !HttpClient, depends on {{{module-main}}}
[[BR]]
External dependencies: commons-logging

This informal unit provides support for client-side management of
connections based on traditional, blocking IO.



=== HttpClient ===

{{{module-client}}} in component !HttpClient, depends on {{{module-main}}}, 
(others in) {{{module-client}}

[Httpcomponents Wiki] Update of "GuidedTourOfHttpCore" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" 
for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/HttpComponents/GuidedTourOfHttpCore

New page:
## pragma section-numbers 2
= A Guided Tour of HttpCore (module-main) =


[[TableOfContents]]


== Welcome ==

Welcome, visitors, to this guided tour of [wiki:Self:HttpComponents HttpCore].
I am your tour guide.
If you could please come a little closer and gather around me,
so I don't have to shout? Thank you, that's much better.
I'm about to give you a short introduction, and then we'll visit
some interesting places in !HttpCore so you can see how it works.
Whenever you've got a question, feel free to ask.
That's what I'm here for, to answer your questions.

As you probably know, HTTP is a protocol for exchanging messages
between a client and a server. It's in widespread use, and it
typically is running on top of plain TCP/IP or secure TLS/SSL sockets.
[[BR]]
Here at [http://www.apache.org/ Apache], there is an implementation
of the client side of that protocol called the Commons HttpClient.
Informally, we also call it "the 3.x codebase" or simply "the old code".
It proved quite useful to a lot of people, but the old code has severe
limitations in it's design.
For example, there is a class called {{{HttpMethodBase}}}.
It represents a request and a response at the same time,
and it also implements logic for processing both.
This kind of design where different things are crammed together
in a single place makes it really hard to maintain or extend the code.

Therefore we started a new successor project called HttpComponents.
Based on the experience gained with the old code, it implements the
HTTP protocol with a new approach. Above all, there are several modules
dealing with different aspects of the big problem.
As you can gather from it's name, the !HttpCore module is at the
very heart of this effort. It defines stuff on which all the other
modules depend and rely.
[[BR]]
!HttpCore deals with representation of HTTP messages, and
with transport logic for sending and receiving those messages.
It also defines a kind of framework infrastructure so other
modules can plug in functionality.
Unlike the old code, !HttpCore is not specific to the client side
of HTTP communication, it can also be used for the server side.
And because it is so fundamentally different from it's predecessor,
we put all the code into an all-new package hierarchy so you
don't confuse them.

 '''Q:''' I have a question.
 [[BR]]
 '''A:''' Yes, please? What would you like to ask?
 [[BR]]
 '''Q:'''
 If it is in a new package hierarchy, applications written
 for the old code will not be able to use the new one?
 [[BR]]
 '''A:'''
 Yes, that is correct. Because the old code was limited in it's design,
 we had to change the API. Applications have to be rewritten to
 make use of the new code. There was no way to avoid this.
 The all-new package names at least make sure that both old and new code
 can be used in the same environment, for example a Servlet engine,
 without interference.

Now, if you would like to follow me to the main hall...
it's called package {{{org.apache.http}}}.
You may want to keep the
[http://hc.apache.org/httpcomponents-core/httpcore/apidocs/index.html JavaDocs]
at hand, that will make it easier for you to follow my explanations.



== Messages ==

The first problem we had to deal with is the representation of messages.
If you don't know how to represent a message, you can't send or receive it,
right?
So here we have a set of interfaces for the building blocks of an HTTP message.
There's the {{{RequestLine}}} for a request and the
{{{StatusLine}}} for a response, both containing a {{{ProtocolVersion}}}.
The latter is so elementary that we made it a class instead of an interface,
and of course we have the {{{HttpVersion}}} derived from it.
Then we have a {{{Header}}} with name and value, where the value
can have multiple {{{HeaderElement}}}s. And finally there is the
message body, the {{{HttpEntity}}}.

 '''Q:'''
 {{{HttpVersion}}} derived from {{{ProtocolVersion}}}?
 Wouldn't the protocol always be HTTP in HttpCore?
 [[BR]]
 '''A:'''
 Not quite. There is at least one other protocol,
 the Session Initiation Protocol SIP,
 which has a message format identical to that of HTTP.
 Only the protocol name and version differs.
 Since it's so similar, we tried to keep the door open.
 [[BR]]
 '''Q:''' That makes sense.

So, out of these building blocks, we collect messages.
Every {{{HttpMessage}}} has headers, which can be added or deleted at will.
{{{HttpRequest}}} adds the request line,
{{{HttpEntityEnclosingRequest}}} an entity.
{{{HttpResponse}}} adds a status line and also an entity.
For convenient integration into frameworks that explore the Factory pattern,
there are factory interfaces for both requests and responses.

 '''Q:''' Aren't there responses without an entity?
 [[BR]]
 ''

Re: [g...@vmgump]: Project commons-httpclient (in module httpcomponents) failed

Hi Sebastian, Oleg,

>>> svn: URL 
>>> 'http://svn.apache.org/repos/asf/httpcomponents/httpcomponents/gump-trun...
>>> k' doesn't exist
>>>
>> Roland
>>
>> I am unable to find where this god damn URL is referenced. What do I
>> have to do to make GUMP happy again?
> 
> I thought I fixed that particular URL by editting
> 
> https://svn.apache.org/repos/asf/gump/metadata/project/httpcomponents.xml
> 
> to remove the additional httpcomponents path element.

Yes, I noticed yesterday evening that somebody fixed the paths.

> However, other errors are now occurring.

I created the gump-trunk after moving the old codebase, but forgot
to update it when Oleg had moved the component sources. gump-trunk
was still pointing to the Jakarta repository for those. Fixed now.

cheers,
  Roland


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [HttpCore] HttpCore 4.0-beta1 release packages preview (4th take)

On 20/01/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
> Sebastian et al
>
> The problem appears to have been fixed. Please feel free to test the
> latest SVN snapshots.
>
> The preview packages can be found below:
>
> http://people.apache.org/~olegk/httpcore-4.0-beta1-preview/RELEASE_NOTES.txt
> http://people.apache.org/~olegk/httpcore-4.0-beta1-preview/packages/
>
> I would like to cut the final release packages and call a vote on the
> release later today.

NIO test now works OK. Yay!

However, mvn test keeps recompiling the sources.

The times in the source zip archive are one hour later than the times
in the tar.gz archive - this is true for me using Winzip on Windows
and unzip/gzip/tar on people.

No idea what causes that, sorry.

It's not a showstopper however, as the hour will soon pass...

>
> Oleg
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Httpcomponents Wiki] Update of "ReferenceMaterials" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" 
for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/HttpComponents/ReferenceMaterials

New page:
= Reference Materials =

This page lists the specifications that are or could be relevant
for the design and implementation of HttpClient 4.0.


== Protocol ==

The Hypertext Transfer Protocol (HTTP) is the only protocol directly
supported by HttpClient. The current version of the protocol is 1.1,
specified by RFC 2616. Version 1.1 maintains backward compatibility
with version 1.0, specified by RFC 1945.
RFC 1945 is obsoleted by RFC 2616, but still relevant for compatibility.

 1. RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1

  * [http://www.ietf.org/rfc/rfc2616.txt RFC 2616 (text)]
  * [http://www.w3.org/Protocols/rfc2616/rfc2616.html RFC 2616 (HTML)]
  * [http://www.w3.org/Protocols/HTTP/1.1/rfc2616.pdf RFC 2616 (PDF)]

 1. RFC 1945: Hypertext Transfer Protocol -- HTTP/1.0 (obsoleted by RFC 2616)

  * [http://www.ietf.org/rfc/rfc1945.txt RFC 1945 (text)]


== Cookies ==

Cookies are the primary means for servers to maintain sessions with clients.
They were originally introduced by Netscape, later standardized in RFC 2109,
and reworked in RFC 2965.
RFC 2109 is obsoleted by RFC 2965, but still relevant for compatibility.
Netscape cookies do not conform to the standardized formats, but are
relevant as well because they are still used frequently.
RFC 2964 documents best practices for using cookies.

 1. RFC 2965: HTTP State Management Mechanism
  * [http://www.ietf.org/rfc/rfc2965.txt RFC 2965 (text)]

 1. RFC 2964: Use of HTTP State Management
  * [http://www.ietf.org/rfc/rfc2964.txt RFC 2964 (text)]

 1. RFC 2109: HTTP State Management Mechanism (obsoleted by RFC 2965)
  * [http://www.ietf.org/rfc/rfc2109.txt RFC 2109 (text)]

 1. Netscape Cookies
  * [http://wp.netscape.com/newsref/std/cookie_spec.html Persistent Client 
State HTTP Cookies] [[BR]] It's called a ''Preliminary Specification'' since it 
was never finalized. Don't worry, this is the actual specification.



== Authentication ==

Servers can ask clients to authenticate before accessing specific resources
or performing restricted operations. The standard authentication mechanisms
are Basic and Digest, both specified in RFC 2617.
Also frequently used is NTLM, a proprietary protocol for which
no complete specification is publicly available.

TLS or SSL with client authentication is '''not''' handled as part of HTTP.
See the section on "Secure Communication" for TLS or SSL.

 1. RFC 2617: HTTP Authentication: Basic and Digest Access Authentication
  * [http://www.ietf.org/rfc/rfc2617.txt RFC 2617 (text)]

 1. NTLM: NT LAN Manager Authentication
  * [http://davenport.sourceforge.net/ntlm.html]


== Secure Communication ==

HTTP communication can be encrypted for confidentiality. Netscape developed
the original technology called SSL (Secure Sockets Layer) for this purpose.
SSL was later enhanced and standardized as TLS (Transport Layer Security)
in RFC 2246. TLS is backward compatible with SSL.
As the name suggests, encryption is handled on a protocol layer below HTTP.
HttpClient does '''not''' implement TLS nor SSL, it just allows to use them
if available.

RFC 2817 specifies the CONNECT method to establish HTTP tunnels
through proxies. Such tunnels can then be switched to secure communication.
RFC 2818 describes how to use HTTP over TLS connections.

 1. RFC 2817: Upgrading to TLS Within HTTP/1.1
  * [http://www.ietf.org/rfc/rfc2817.txt RFC 2817 (text)]

 1. RFC 2818: HTTP Over TLS
  * [http://www.ietf.org/rfc/rfc2818.txt RFC 2818 (text)]


== Miscellaneous ==

=== RFC 1867: Form-based File Upload in HTML ===

RFC 1867 specifies the MIME type application/x-www-form-urlencoded
for sending data from web formulars to HTTP servers. While content
encoding itself is not in the scope of HttpClient, posting form data
is a requirement. HttpClient needs to provide a mechanism to use an
external encoder for generating message bodys with this encoding.

 * [http://www.ietf.org/rfc/rfc1867.txt RFC 1867 (text)]

=== RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax ===

RFC 2396 specifies the primary format for addressing resources on
HTTP servers and elsewhere. HttpClient needs to be able to handle
the format used for addressing HTTP servers.

 * [http://www.ietf.org/rfc/rfc2396.txt RFC 2396 (text)]


=== RFC 3143: Known HTTP Proxy/Caching Problems ===

 * [http://www.ietf.org/rfc/rfc3143.txt RFC 3143 (text)]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Jakarta-httpclient Wiki] Update of "ForAbsoluteBeginners" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-httpclient 
Wiki" for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/jakarta-httpclient/ForAbsoluteBeginners

The comment on the change is:
moved

--
- #pragma section-numbers 2
+ #deprecated
  
- = Client HTTP Programming Primer =
+ This page has been 
[http://wiki.apache.org/HttpComponents/ForAbsoluteBeginners moved] to the new 
[http://wiki.apache.org/HttpComponents/ HttpComponents Wiki].
  
- == About ==
- 
- This document is intended for people who suddenly have to or want to implement
- an application that automates something usually done with a browser,
- but are missing the background to understand what they actually need to do.
- It provides guidance on the steps required to implement a program that
- interacts with a web site which is designed to be used with a browser.
- It does not save you from eventually learning the background of what
- you are doing, but it should help you to get started quickly and learn
- the details later.
- [[BR]]
- This document has evolved from discussions on the HttpClient mailing lists.
- Although it refers to HttpClient, the concepts described here apply equally
- to HttpComponents or SUN's 
[http://java.sun.com/j2se/1.4.2/docs/api/java/net/HttpURLConnection.html 
HttpURLConnection] or any other
- HTTP communication library for any programming language. So you might
- find it useful even if you're not using Java and HttpClient.
- [[BR]]
- The existence of this document does not imply that the HttpClient community
- feels responsible for teaching you how to program a client HTTP application.
- It is merely a way for us to reduce the noise on the mailing list without
- just leaving the newbies out in the cold.
- 
- 
- 
- [[TableOfContents]]
- 
- 
- 
- == Scenario ==
- 
- Let's assume that you have some kind of repetitive, web-based task that
- you want to automate. Something like:
- 
-  * goto page http:''//xxx.yyy.zzz/login.html
-  * enter username and password in a web form and hit the "login" button
-  * navigate to a specific page
-  * check the number/headline/whatever shown on that page
- 
- At this time, we don't have a specific example which could be developed
- into a sample application. So this document is all bla-bla, and you will
- have to work out the details - all the details - yourself. Such is life.
- 
- 
- === Caveat ===
- 
- This scenario describes a hobbyist usage of HTTP, in other words:
- '''a bad practice'''. Web sites are designed for user interaction, not
- as an application programming interface (API). The interface of a
- web site is the user interface displayed by a browser. The HTTP
- communication between the browser and the server is an internal API,
- subject to change without notice.
- [[BR]]
- A web site can be redesigned at any point in time. The server then
- sends different documents and a browser will display the new content.
- The user easily adjusts to click the appropriate links, and the browser
- communicates via HTTP as specified by the new documents from the server.
- Your application that only mimicks a browser will simply break.
- [[BR]]
- Nevertheless, implementing this scenario will help you to get
- familiar with HTTP communication. It is also "good enough" for
- hobbyists applications, for example if you want to download the
- latest installment of your favorite daily webcomic to install
- it as the screen background. There is no big damage if such an
- application breaks.
- 
- If you want to implement a solid application, you should use only
- published APIs. For example, to check for new mail on your webmail
- account, you should ask the webmail provider for POP or IMAP access.
- These are standardized protocols supported my most EMail client applications.
- If you want to have a newsticker, look for RSS feeds from the provider and
- applications that display them.
- [[BR]]
- As another example, if you want to perform a web search, there are
- search companies that provide an API for using their search engines.
- Unlike the examples before, such APIs are proprietary. You will still
- have to implement an application, but then you are using a published API
- that the provider will not change without notice.
- 
- 
- 
- == Not a Browser ==
- 
- HttpClient is not a browser. Here's the difference.
- 
- 
- === Browser ===
- 
- attachment:browser.png
- 
- The figure shows some of the components you will find in a browser.
- To the left, there is the user interface. The browser needs a rendering
- engine to display pages, and to interpret user input such as mouse clicks
- somewhere on the displayed page. There is a layout engine which computes
- how an HTML page should be displayed, including cascading style sheets
- and images. A Java''Script interpreter runs Java''Script code 
embedded in
- or refere

[Httpcomponents Wiki] Update of "ForAbsoluteBeginners" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" 
for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/HttpComponents/ForAbsoluteBeginners

New page:
#pragma section-numbers 2

= Client HTTP Programming Primer =

== About ==

This document is intended for people who suddenly have to or want to implement
an application that automates something usually done with a browser,
but are missing the background to understand what they actually need to do.
It provides guidance on the steps required to implement a program that
interacts with a web site which is designed to be used with a browser.
It does not save you from eventually learning the background of what
you are doing, but it should help you to get started quickly and learn
the details later.
[[BR]]
This document has evolved from discussions on the HttpClient mailing lists.
Although it refers to HttpClient, the concepts described here apply equally
to HttpComponents or SUN's 
[http://java.sun.com/j2se/1.4.2/docs/api/java/net/HttpURLConnection.html 
HttpURLConnection] or any other
HTTP communication library for any programming language. So you might
find it useful even if you're not using Java and HttpClient.
[[BR]]
The existence of this document does not imply that the HttpClient community
feels responsible for teaching you how to program a client HTTP application.
It is merely a way for us to reduce the noise on the mailing list without
just leaving the newbies out in the cold.



[[TableOfContents]]



== Scenario ==

Let's assume that you have some kind of repetitive, web-based task that
you want to automate. Something like:

 * goto page http:''//xxx.yyy.zzz/login.html
 * enter username and password in a web form and hit the "login" button
 * navigate to a specific page
 * check the number/headline/whatever shown on that page

At this time, we don't have a specific example which could be developed
into a sample application. So this document is all bla-bla, and you will
have to work out the details - all the details - yourself. Such is life.


=== Caveat ===

This scenario describes a hobbyist usage of HTTP, in other words:
'''a bad practice'''. Web sites are designed for user interaction, not
as an application programming interface (API). The interface of a
web site is the user interface displayed by a browser. The HTTP
communication between the browser and the server is an internal API,
subject to change without notice.
[[BR]]
A web site can be redesigned at any point in time. The server then
sends different documents and a browser will display the new content.
The user easily adjusts to click the appropriate links, and the browser
communicates via HTTP as specified by the new documents from the server.
Your application that only mimicks a browser will simply break.
[[BR]]
Nevertheless, implementing this scenario will help you to get
familiar with HTTP communication. It is also "good enough" for
hobbyists applications, for example if you want to download the
latest installment of your favorite daily webcomic to install
it as the screen background. There is no big damage if such an
application breaks.

If you want to implement a solid application, you should use only
published APIs. For example, to check for new mail on your webmail
account, you should ask the webmail provider for POP or IMAP access.
These are standardized protocols supported my most EMail client applications.
If you want to have a newsticker, look for RSS feeds from the provider and
applications that display them.
[[BR]]
As another example, if you want to perform a web search, there are
search companies that provide an API for using their search engines.
Unlike the examples before, such APIs are proprietary. You will still
have to implement an application, but then you are using a published API
that the provider will not change without notice.



== Not a Browser ==

HttpClient is not a browser. Here's the difference.


=== Browser ===

attachment:browser.png

The figure shows some of the components you will find in a browser.
To the left, there is the user interface. The browser needs a rendering
engine to display pages, and to interpret user input such as mouse clicks
somewhere on the displayed page. There is a layout engine which computes
how an HTML page should be displayed, including cascading style sheets
and images. A Java''Script interpreter runs Java''Script code embedded 
in
or referenced from HTML pages. Events from the user interface are passed
to the Java''Script interpreter for processing.
On the top, there are interfaces for plugins that can handle Applets,
embedded media objects like PDF files, Quicktime movies and Flash animations,
or ActiveX controls that can do anything.

In the center of the figure you can find internal components. Browsers
have a cache of recently accessed documents and image files. They need
to remember cookies and passwords entered

[Httpcomponents Wiki] Update of "FrontPage" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" 
for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/HttpComponents/FrontPage

The comment on the change is:
moving two pages

--
  == Table of Contents ==
  
   * Users
-1. http://wiki.apache.org/jakarta-httpclient/HttpClientPowered - A list of 
applications that use !HttpClient
+1. HttpClientPowered - A list of applications that use !HttpClient
-1. [http://wiki.apache.org/jakarta-httpclient/ForAbsoluteBeginners Client 
HTTP Programming Primer]
+1. [wiki:Self:ForAbsoluteBeginners Client HTTP Programming Primer]
 1. [http://wiki.apache.org/jakarta-httpclient/GuidedTourOfHttpCore Guided 
Tour of HttpCore] - Overview documentation for HttpComponents Core
 1. 
[http://wiki.apache.org/jakarta-httpclient/FrequentlyAskedApplicationDesignQuestions
 Application Design FAQ]
 1. 
[http://wiki.apache.org/jakarta-httpclient/FrequentlyAskedConnectionManagementQuestions
 Connection Management FAQ] - What is TIME_WAIT etc
 1. [http://wiki.apache.org/jakarta-httpclient/AlternativeJSSE JSSE 
Implementations] - Links to JSSE implementations for HTTPS connectivity
-1. [wiki:Self:FrequentlyAskedNTLMQuestions NTLM FAQ]
+1. [http://wiki.apache.org/jakarta-httpclient/FrequentlyAskedNTLMQuestions 
NTLM FAQ]
  
   * Development
 1. http://wiki.apache.org/jakarta-httpclient/WebSite - How to update and 
deploy the HttpComponents website

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Httpcomponents Wiki] Update of "HttpClientPowered" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" 
for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/HttpComponents/HttpClientPowered

New page:
The following projects and applications use or used to use Commons !HttpClient, 
our old codebase.

[http://jakarta.apache.org/slide/ Jakarta Slide]
Jakarta Slide is an open-source project composed of multiple modules tied 
together using WebDAV. It includes a CM API, a WebDAV server, WebDAV client 
APIs, J2EE compliant stores and more. 

[http://www.jcp.org/en/jsr/detail?id=147 JSR 147]
Workspace Versioning and Configuration Management. Software AG is going to 
implement the current draft of JSR 147 API. The implementation will be based on 
the Jakarta Commons HttpClient and located in the Jakarta Slide project. 

[http://jakarta.apache.org/commons/latka/ Jakarta Commons Latka]
Latka is a functional (end-to-end) testing tool. It is implemented in Java, 
and uses an XML syntax to define a series of HTTP (or HTTPS) requests and a set 
of validations used to verify that the request was processed correctly. 

[http://jakarta.apache.org/cactus/ Jakarta Cactus]
Cactus is a simple test framework for unit testing server-side java code. 
The intent of Cactus is to lower the cost of writing tests for server-side 
code. 

[http://jakarta.apache.org/jmeter/ Apache JMeter]
JMeter is a pure Java application designed to load test functional behavior 
and measure performance. It was originally designed for testing Web 
Applications only but has since expanded to other test functions.

[http://servicemix.org/ ServiceMix]
ServiceMix is an open source Enterprise Service Bus (ESB) based around the 
Java Business Integration specification 
[http://www.jcp.org/en/jsr/detail?id=208 JSR 208] under the Apache 2.0 licence. 
ServiceMix consists of a JBI container and component suite, 
[http://servicemix.org/Components massive connectivity to many protocols] with 
complete integration with Spring and Geronimo as well as supporting straight 
through, SEDA and clustered message flows, smart routing and transformations 
and orchestration via BPEL.

[http://htmlunit.sourceforge.net/ HtmlUnit]
Html``Unit is a java unit testing framework for testing web based 
applications. Html``Unit models the returned document so that you deal with 
pages and forms and tables. 

[http://xins.sourceforge.net/ The XINS/Java Client Framework]
XINS is a framework for describing and implementing API's that can be 
accessed by browsers. In contrast to SOAP and XML-RPC, HTML-based test forms 
can be generated to make calls to the API 

[http://www.limewire.org/ LimeWire]
Lime``Wire is a robust, open-source, multi-platform, consumer-oriented P2P 
file-sharing client. Lime``Wire uses HttpClient because it is a highly 
customizable and efficient HTTP manager, and has proven itself to work without 
any hitches on the hundreds of thousands of daily users of Lime``Wire 

[http://crawler.archive.org/ Heritrix]
Heritrix is the [http://www.archive.org/ Internet Archive's] open-source, 
extensible, web-scale, archival-quality web crawler project. 

[http://www.xsmiles.org/ X-Smiles]
X-Smiles is an Open-Source XML parser, that has extensive standards 
support. 

[http://www.openlaszlo.org/ Laszlo Presentation Server]
The Laszlo Presentation Server is an XML-native platform for the 
development and delivery of a new generation of Rich Internet Applications. 

[http://www.nortelnetworks.com/ Nortel Networks]
Operator Simulation Tool (OST) - A server side performance and scalability 
testing tool uses HttpClient to drive loads to web based server applications. 

[http://www.mindiq.com/elearning/dac/index.php MindIQ's Design-a-Course]
Design-a-Course, a quick, easy, and inexpensive e-learning software tool 
allows novice users to create sophisticated web-based training (WBT) courses 
within minutes. 

[http://www3.contactoffice.com/ ContactOffice]
ContactOffice is a complete groupware solution ('Virtual office') combining 
mail, calendar, storage, contacts, and more. HttpClient is used for back-end 
tasks such as inter-server communication and SMS transmission. 

[http://www.newknow.com/ Newknow]
Newknow is a Knowledge Management Suite based on Artificial Intelligence, 
Collaboration and Document Management and we use Commons HttpClient as part of 
our Knowledge Spider. This Spider retrieves all the information gathered by the 
Agents and the corporative sources on the network. 

[http://www.xam.de/dev/de4d2c/ Web Abstraction Layer (WAL)]
Web Abstraction Layer (formerly known as de4d2c) - development environment 
4 documents 2 content - is an in-browser web page wrapper development system 
that returns it's extraction result as XML using XSLT generated from intuitive 
user input. Commons HttpClient is used as the robust base of the whole system. 

[http://www.reflexe.fr/h

[Httpcomponents Wiki] Update of "FrontPage" by RolandWeber

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" 
for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/HttpComponents/FrontPage

--
  #format wiki
  #language en
  #pragma section-numbers off
- = WikiName Wiki =
  
- What is this wiki about?
+ = Welcome to the HttpComponents Wiki =
  
+ This wiki provides additional documentation for HttpClient and 
HttpComponents.  Formal documentation is available from the 
[http://hc.apache.org/ HttpComponents website].  Users are encouraged to 
contribute information to this wiki that may be useful to others.  Please note 
that as an anti-spam measure, you must be logged in to edit pages.  You can use 
[UserPreferences] to create an account or login.
- Interesting starting points:
-  * RecentChanges: see where people are currently working
-  * WikiSandBox: feel free to change this page and experiment with editing
-  * FindPage: search or browse the database in various ways
-  * SyntaxReference: quick access to wiki syntax
-  * SiteNavigation: get an overview over this site and what it contains
  
+ The HttpComponents wiki is a part of the big [http://wiki.apache.org/ Apache 
Wiki Farm].
+ We originally created content in the
+ [http://wiki.apache.org/jakarta-httpclient/ Jakarta HttpClient Wiki]
+ and are still in the process of moving it here.
+ We apologize for the broken links during the transition. 
  
- == How to use this site ==
+ If you're new to wikis you might want to read HelpForBeginners to get an idea 
of how they work and how you can contribute.
  
+ == Table of Contents ==
- A Wiki is a collaborative site, anyone can contribute and share:
-  * Edit any page by pressing '''[[GetText(Edit)]]''' at the top or the bottom 
of the page 
-  * Create a link to another page with joined capitalized words (like 
WikiSandBox) or with {{{["quoted words in brackets"]}}}
-  * Search for page titles or text within pages using the search box at the 
top of any page
-  * See HelpForBeginners to get you going, HelpContents for all help pages.
  
- To learn more about what a WikiWikiWeb is, read about MoinMoin:WhyWikiWorks 
and the MoinMoin:WikiNature. Also, consult the MoinMoin:WikiWikiWebFaq. 
+  * Users
+1. http://wiki.apache.org/jakarta-httpclient/HttpClientPowered - A list of 
applications that use !HttpClient
+1. [http://wiki.apache.org/jakarta-httpclient/ForAbsoluteBeginners Client 
HTTP Programming Primer]
+1. [http://wiki.apache.org/jakarta-httpclient/GuidedTourOfHttpCore Guided 
Tour of HttpCore] - Overview documentation for HttpComponents Core
+1. 
[http://wiki.apache.org/jakarta-httpclient/FrequentlyAskedApplicationDesignQuestions
 Application Design FAQ]
+1. 
[http://wiki.apache.org/jakarta-httpclient/FrequentlyAskedConnectionManagementQuestions
 Connection Management FAQ] - What is TIME_WAIT etc
+1. [http://wiki.apache.org/jakarta-httpclient/AlternativeJSSE JSSE 
Implementations] - Links to JSSE implementations for HTTPS connectivity
+1. [wiki:Self:FrequentlyAskedNTLMQuestions NTLM FAQ]
  
- This wiki is powered by MoinMoin.
+  * Development
+1. http://wiki.apache.org/jakarta-httpclient/WebSite - How to update and 
deploy the HttpComponents website
+1. [http://wiki.apache.org/jakarta-httpclient/HttpClientReleaseProcess 
Commons HttpClient 3.x release process] - How to cut and publish a release of 
Commons !HttpClient 3.x
+1. 
[http://wiki.apache.org/jakarta-httpclient/HttpComponentsCoreReleaseProcess 
HttpComponents Core release process] - How to cut and publish a release of 
!HttpComponents Core
+1. 
http://wiki.apache.org/jakarta-httpclient/HttpClientApiJavadocGuidelines - API 
Java''Doc guidelines for !HttpComponents
+1. http://wiki.apache.org/jakarta-httpclient/ConnectionManagementDesign - 
Design considerations for connection management in !HttpComponents
+1. http://wiki.apache.org/jakarta-httpclient/HttpComponentsAndOSGi - 
Generating OSGi bundles for our modules
+1. http://wiki.apache.org/jakarta-httpclient/ReferenceMaterials - Links to 
relevant standards
  
+  * Benchmarks
+1. 
http://wiki.apache.org/jakarta-httpclient/HttpClient3vsHttpClient4vsHttpCore - 
!HttpClient 3.x vs !HttpClient 4.x vs !HttpCore 4.x performance benchmarks
+ 
+  * Formalities
+1. [http://wiki.apache.org/jakarta-httpclient/BoardReports Board Reports]
+ 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[HttpCore] HttpCore 4.0-beta1 release packages preview (4th take)

Sebastian et al

The problem appears to have been fixed. Please feel free to test the
latest SVN snapshots.

The preview packages can be found below:  

http://people.apache.org/~olegk/httpcore-4.0-beta1-preview/RELEASE_NOTES.txt
http://people.apache.org/~olegk/httpcore-4.0-beta1-preview/packages/

I would like to cut the final release packages and call a vote on the
release later today.

Oleg


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [g...@vmgump]: Project commons-httpclient (in module httpcomponents) failed

On 20/01/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2008-01-18 at 12:07 +0100, [EMAIL PROTECTED] wrote:
> > Hi folks,
> >
> > looks like I screwed up when defining the repo and
> > path for our GUMP projects [1]:
> >
> > Tail of Update : update_httpcomponents
> >
> > This is a very short tail of the log at update_httpcomponents
> >
> > svn: URL 
> > 'http://svn.apache.org/repos/asf/httpcomponents/httpcomponents/gump-trun...
> > k' doesn't exist
> >
>
> Roland
>
> I am unable to find where this god damn URL is referenced. What do I
> have to do to make GUMP happy again?

I thought I fixed that particular URL by editting

https://svn.apache.org/repos/asf/gump/metadata/project/httpcomponents.xml

to remove the additional httpcomponents path element.

However, other errors are now occurring.

> Oleg
>
>
> > Details
> > Repository
> >
> > * Repository: httpcomponents
> > * SVN Directory: httpcomponents/gump-trunk
> > * SVN URL: 
> > http://svn.apache.org/repos/asf/httpcomponents/httpcomponents/gump-trunk
> > * Redistributable: True
> >
> >
> > I can take care of it on Saturday evening or Sunday.
> >
> > cheers,
> >   Roland
> >
> > [1] 
> > http://vmgump.apache.org/gump/public/httpcomponents/commons-httpclient/index.html
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: unable to encode reserved characters using java.net.URI multi-arg constructors


On Sat, 2008-01-19 at 09:33 -0800, Sam Berlin wrote:
> > Here's my take. There is nothing wrong with j.u.URI as such. It just
> > needs a better parser that can deal with escaped and unescaped queries,
> > as well as be more lenient about common non-compliant behaviors, and
> > then construct the URI instance using a multi-arg constructor. It was
> > long on my virtual to-do list to open a feature request for pluggable
> > URI parsers in JIRA. Probably it is about time.
> >
> > Would that work for LimeWire?
> >
> > Oleg
> >
> 
> It almost certainly would work, however HttpClient would then be
> broken (as far as URI parsing goes) for everyone else.  As others have
> pointed out (and as Tim explained to me in sad detail), URI is just
> basically broken when it comes to using it with the multi-arg
> constructors.  It's flat-out impossible to recreate a URI with the
> multi-arg constructors and have it point to the correct resource.
> 
> Sam
> 

Sam

What would be your suggestion on dealing with the issue? Is there anyway
we could avoid rewriting the whole URI class and leverage functionality
already available in the JRE?  

Oleg


> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Draft of Project Charter


On Sun, 2008-01-20 at 09:21 +0100, Roland Weber wrote:
> Hi folks,
> 
> I've just redeployed the site with a new draft of
> our Charter. It will appear here shortly:
> http://hc.apache.org/charter.html
> 
> Compared to the previous project scope presented
> in the same location, I've dropped the "collaborates
> with other projects" item. We're helping all our
> users as best we can, be they Apache projects or not.
> If some of use choose to engage in other projects
> to a greater extend, that is a personal decision
> and not part of our project scope.
> I've also put in items for new components and for the
> possibility of hosting components-based applications.
> The wording does not refer to HttpClient 3.1 as a
> component, a subtle but relevant detail.
> 
> Please let me know what you think, or simply update
> the draft.
> 

+1 

Oleg

> I've also put some time into drafting Bylaws, but
> these need more work until they are ready for review.
> 
> cheers,
>   Roland
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [HttpCore] HttpCore 4.0-beta1 release packages preview (3nd take)

On Sun, 2008-01-20 at 03:14 +, sebb wrote:
> Done some more testing.
> 
> Looks like the problem may be that when port 9998 is closed, sometimes
> the SelectionKey for the  channel becomes invalid.
> 
> I created a wrapper class for SelectionKey in
> DefaultListeningIOReactor to keep track of calls to cancel(); this
> seems to show that the key can become invalid *without* being
> cancelled...
> 
> It's not clear how this happens.
> 

Hi Sebastian,

I think this is because the channel associated with that key gets closed
before the key itself is canceled. Ain't NIO fun?

I think I have found the cause of the problem. NIO code on Windows still
appears buggy or at the very least its behavior is inconsistent with
that of common *nix platforms.

I checked in a workaround for the problem and am in the process of doing
some final testing

> There is an "interesting" package private method
> AbstractSelectionKey#invalidate() which just sets valid=false. Could
> this be called internally?
> 
> Getting late; might try running that under debug tomorrow.
> 

Do not waste any more of your time on debugging. The problem is
perfectly reproducible on my single core Windows box and I should be
able to fix it in the course of the day

Oleg

> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [g...@vmgump]: Project commons-httpclient (in module httpcomponents) failed


On Fri, 2008-01-18 at 12:07 +0100, [EMAIL PROTECTED] wrote:
> Hi folks,
> 
> looks like I screwed up when defining the repo and
> path for our GUMP projects [1]:
> 
> Tail of Update : update_httpcomponents
> 
> This is a very short tail of the log at update_httpcomponents
> 
> svn: URL 
> 'http://svn.apache.org/repos/asf/httpcomponents/httpcomponents/gump-trun...
> k' doesn't exist
> 

Roland

I am unable to find where this god damn URL is referenced. What do I
have to do to make GUMP happy again?

Oleg


> Details
> Repository
> 
> * Repository: httpcomponents
> * SVN Directory: httpcomponents/gump-trunk
> * SVN URL: 
> http://svn.apache.org/repos/asf/httpcomponents/httpcomponents/gump-trunk
> * Redistributable: True
> 
> 
> I can take care of it on Saturday evening or Sunday.
> 
> cheers,
>   Roland
> 
> [1] 
> http://vmgump.apache.org/gump/public/httpcomponents/commons-httpclient/index.html
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[g...@vmgump]: Project httpcomponents-core (in module httpcomponents) failed

2008-01-20 Thread GUMP

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project httpcomponents-core has an issue affecting its community integration.
This issue affects 3 projects,
 and has been outstanding for 6 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- httpcomponents-client :  HTTP Component: Client
- httpcomponents-core :  HTTP Component: Core
- httpcomponents-core-tests :  Unit Tests for HTTP Component: Core


Full details are available at:

http://vmgump.apache.org/gump/public/httpcomponents/httpcomponents-core/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -INFO- Making directory for Maven properties: 
[/srv/gump/public/workspace/httpcomponents/httpcore]
 -DEBUG- (Gump generated) Maven Properties in: 
/srv/gump/public/workspace/httpcomponents/httpcore/profiles.xml
 -INFO- Failed with reason build failed
 -INFO- Project Reports in: 
/srv/gump/public/workspace/httpcomponents/httpcore/module-main/target/surefire-reports
 -WARNING- No directory 
[/srv/gump/public/workspace/httpcomponents/httpcore/module-main/target/surefire-reports]
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/httpcomponents/httpcomponents-core/gump_work/build_httpcomponents_httpcomponents-core.html
Work Name: build_httpcomponents_httpcomponents-core (Type: Build)
Work ended in a state of : Failed
Elapsed: 2 secs
Command Line: mvn install 
[Working Directory: /srv/gump/public/workspace/httpcomponents/httpcore]
CLASSPATH: 
/usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/apache-commons/collections/build/commons-collections-20012008.jar:/srv/gump/public/workspace/apache-commons/lang/commons-lang-20012008.jar:/srv/gump/public/workspace/jakarta-oro/jakarta-oro-20012008.jar:/srv/gump/public/workspace/junit/dist/junit-20012008.jar:/srv/gump/public/workspace/velocity-engine/bin/velocity-20012008.jar:/srv/gump/public/workspace/velocity-engine/bin/velocity-dep-20012008.jar
-
[INFO] Scanning for projects...
[INFO] 

[INFO] Building Maven Default Project
[INFO]task-segment: [install]
[INFO] 

[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Cannot execute mojo: resources. It requires a project with an existing 
pom.xml, but the build is not using one.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 1 second
[INFO] Finished at: Sun Jan 20 02:43:29 GMT-08:00 2008
[INFO] Final Memory: 2M/5M
[INFO] 
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/httpcomponents/httpcomponents-core/rss.xml
- Atom: 
http://vmgump.apache.org/gump/public/httpcomponents/httpcomponents-core/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.3.
Gump Run 1920012008, vmgump:vmgump-public:1920012008
Gump E-mail Identifier (unique within run) #23.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[g...@vmgump]: Project commons-httpclient (in module httpcomponents) failed

2008-01-20 Thread GUMP

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-httpclient has an issue affecting its community integration.
This issue affects 36 projects,
 and has been outstanding for 6 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- ant-contrib :  Useful little Ant tasks
- ant-contrib-test :  Useful little Ant tasks
- antbook-diary-core :  Examples to go with Java Development with Ant
- antbook-sections :  Examples to go with Java Development with Ant
- apollo :  Apollo Project
- authx-example :  Apache Authentication and Authorization Framework
- authx-script :  Apache Authentication and Authorization Framework
- cddlm :  Configuration and Deployment of Grid Applications and System...
- commons-httpclient :  HTTP Client Library, version 3.1
- commons-jelly-tags-http :  Commons Jelly
- commons-jelly-tags-jetty :  Commons Jelly
- commons-jelly-tags-soap :  Commons Jelly
- excalibur-fortress-bean :  Repository of reusable components.
- excalibur-fortress-container-impl :  Repository of reusable components.
- excalibur-fortress-container-test :  Repository of reusable components.
- excalibur-fortress-examples :  Repository of reusable components.
- excalibur-fortress-migration :  Repository of reusable components.
- excalibur-fortress-platform :  Repository of reusable components.
- excalibur-fortress-testcase :  Repository of reusable components.
- excalibur-monitor :  Repository of reusable components.
- excalibur-sourceresolve :  Repository of reusable components.
- excalibur-xmlutil :  Repository of reusable components.
- groovy :  New agile dynamic language using a Java-like syntax for the ...
- invicta :  Open-source build management tool.
- ivy :  Ivy Core
- ivy-tests :  Ivy is a tool for managing (recording, tracking, resolving 
a...
- maven :  Project Management Tools
- maven-bootstrap :  Project Management Tools
- muse :  Muse Project
- smartfrog :  Smartfrog: Application Deployment from HP Laboratories
- smartfrog-components :  Smartfrog: Application Deployment from HP 
Laboratories
- smartfrog-tasks :  Smartfrog: Application Deployment from HP Laboratories
- smartfrog-tasks-test :  Smartfrog: Application Deployment from HP 
Laboratories
- smartfrog-test :  Smartfrog: Application Deployment from HP Laboratories
- smartfrog-testharness :  Smartfrog: Application Deployment from HP 
Laboratories
- wss4j :  WS-FX Project


Full details are available at:

http://vmgump.apache.org/gump/public/httpcomponents/commons-httpclient/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-httpclient.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/httpcomponents/commons-httpclient/gump_work/build_httpcomponents_commons-httpclient.html
Work Name: build_httpcomponents_commons-httpclient (Type: Build)
Work ended in a state of : Failed
Elapsed: 
Command Line: /usr/lib/jvm/java-1.5.0-sun/bin/java -Djava.awt.headless=true 
-Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only dist 
[Working Directory: /srv/gump/public/workspace/httpcomponents/oac.hc3x]
CLASSPATH: 
/usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/httpcomponents/oac.hc3x/target/classes:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/packages/junit3.8.1/junit.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-20012008.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-20012008.jar:/srv/gump/public/workspace/apache-commons/codec/dist/commons-codec-20012008.jar
 
:/srv/gump/packages/jsse1.0.3/lib/jcert.jar:/srv/gump/packages/jsse1.0.3/lib/jnet.jar:/srv/gump/pac

Draft of Project Charter