commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Dever" <>
Subject RE: [httpclient] Add dependancy on commons-collections
Date Wed, 04 Sep 2002 14:52:45 GMT

While I don't agree with Vincent's proposed solution, I do agree that
introducing a library dependancy would be undesirable at this point.
However I cant ignore that the commons-collections SequencedHashMap is just
the perfect datastructure for the job.  I think we should find a way to use
it and potentially other collections objects in the future.

How about we just drop the SequencedHashMap into HttpClient.  Two possible
ways to do this:
1) include the .class file at packaging time.  This would save us from
having to include the source, but could lead to class loader problems for
clients that actually use commons-collections.

2) include the .java file in the source tree.  The package name for the
hashMap could be changed and be given package only access so that clients
would not use the hashMap.  This would be removed in a future version if
commons-collections is added as a dependancy.

I personally would prefer 2) because it has the least unknowns and provides
the most control, but find it kinda kludgey.  

-----Original Message-----
From: Vincent Massol []
Sent: Wednesday, September 04, 2002 4:30 AM
To: 'Jakarta Commons Developers List'
Subject: RE: [httpclient] Add dependancy on commons-collections

> -----Original Message-----
> From: jsdever [mailto:jsdever] On Behalf Of Jeff Dever
> Sent: 04 September 2002 02:10
> To: Jakarta Commons Developers List
> Subject: RE: [httpclient] Add dependancy on commons-collections
> I see your point.
> I really would like to use this SequencedHashMap, and become more
> familar with the commons-collections.  There are some alternatives.

I don't think this is really required at this point in time. I say,
let's get a stable 2.0 release out and add this dependency on
collections to the following release if you wish.

> 1) We could include the commons-collections.jar into the
> commons-httpclient.jar.  This might lead to class loader problems and
> would be a large waste.

This is not a good solution.

> 2) We could just include the parts of collections (just that one class
> hopefully) in httpclient.  This could be done safely in code form but
> would lead to problems updating it.

If you really want to use SequencedHashMap, that could a temporary
solution for 2.0 until (and if) HttpClient moves to collections in the

> Any other suggestions?

Simply don't use collections. For the case at hand it really isn't that

headerPositions: A Hashtable containing: key=header name, value=position
in list (vector)
headerValues: A vector of headers in the order they were received.

public String getHeader(String headerName)
    Integer position = (Integer)headerPositions.get(headerName);

public String getHeader(int position)
    return headerValues.elementAt(position);

Now to create the structure:

For each header object:

headerPositions.put(header.getName(), new Integer(headerValues.size() -

or something like that ...

Obviously I have taken into account the fact that there could be several
returned headers with the same name so you actually need to store a
Vector of Integer in headerPositions instead of a single Integer. But
that's still very easy to write ... I can provide the code if you wish


> -jeff
> I would be strongly -1 to do that (although I am not a committer).
> Cactus is using HttpClient and I would hate to have to tell all Cactus
> users
> that they should now add one more jar to all their client side and
> server side classpaths without gaining a single new feature for them.
> -Vincent
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-
> For additional commands, e-mail: <mailto:commons-dev-

To unsubscribe, e-mail:
For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message