DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24678.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi Robert,
Thank you for your excellent care.
This is open source at it's best.
The way I see it is that Jelly is a good way to build actions.
Actions you can then invoke many ways
(eg. with a tag from jsp page, from command line ...)
Thus jelly works as a wrapper for all kinds of
tools,
from:Arun Thomas [EMAIL PROTECTED]
Any chance you could provide a package dependency diagram (in text is fine) for the
structure you envision? Are there any commons conventions on such dependencies?
In essence the package dependencies are as you would expect.
collection depends on
Will do!
And I agree with you about using Jelly for 'actions'. I've written apps
that used Struts for a controller and had a single action that invoked
Jelly scripts. So essentially all of my processing logic, be it DB
access, prepping a Struts form bean for editing, or even business logic,
from:__matthewHawthorne [EMAIL PROTECTED]
Packages for collection, set, list, buffer, bag, and map look good to
me. The decorators package can just be split up and categorized
accordingly.
However, I disagree with a few things. For example, are there enough
BidiMap
Howdy,
+1, I'm reading this with disbelief that he doesn't have commons karma
already ;)
Yoav Shapira
Millennium ChemInformatics
-Original Message-
From: robert burrell donkin
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 12, 2003 2:16 PM
To: Jakarta Commons Developers List
Howdy,
I'm sorry I didn't get to add more examples at this point. I won't
touch the CVS anymore, but will try to add examples to release 1.1.
Yoav Shapira
Millennium ChemInformatics
-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 11, 2003 8:19
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24678.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
There seems to be a bug with ExtensionFunctions and collections as
parameters.
Example:
List list = new ArrayList();
list.add(foo);
list.add(bar);
context.getVariables().declareVariable(myList, list); Collection
values = context.getValue(test:getItems($myList));
* Values returns: [bar, bar] not
--
Vote: Elect Simon Kitching As Jakarta Commons Committer
[X] +1 Yes let him commit!
[ ] +0
[ ] -0
[ ] -1 I am against this (please include a reason).
The following comment has been added to this issue:
Author: Paul Libbrecht
Created: Thu, 13 Nov 2003 11:01 AM
Body:
Grumpfs, it's back !
(I can't seem to be able to re-open it).
The reason is jelly-tags/tag-project.xml which had such a dependency on
dom4j-1.4-dev8...
Of course,
Is Commons a place for web applications? I've always thought it was for
small components to be used in web apps.
David
--- Shapira, Yoav [EMAIL PROTECTED] wrote:
Hi,
I've written a tiny webapp to function as a load balancer. It is a
rules-based balancer, rather than round-robyn or another
Howdy,
That's a good point. I'm not sure if commons is an appropriate place
for this; what is a better option? I suppose I could always just put it
in SourceForge or something similar.
Yoav Shapira
Millennium ChemInformatics
-Original Message-
From: David Graham [mailto:[EMAIL
There is a perception in some circles that Jakarta as a whole, and Jakarta
Commons in particular, is too large for sufficient PMC oversight. In my
opinion, particularly with respect to Jakarta Commons, this is not the
case, but one way to combat that perception is to recognize that although
the
+1 though I suspect determining the final list to remove will take a
while.
David
--- Rodney Waldhoff [EMAIL PROTECTED] wrote:
There is a perception in some circles that Jakarta as a whole, and
Jakarta
Commons in particular, is too large for sufficient PMC oversight. In
my
opinion,
Howdy,
+1, and it seems like the final list was already in Senor Waldhoff's
original email...
Yoav Shapira
Millennium ChemInformatics
-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 12:43 PM
To: Jakarta Commons Developers List
Subject:
Howdy,
Actually, I'm curious to know how you obtained this list: some script
with mixed CVS commands? I'd like to come up with similar lists for
other modules where I'm a committer. I *know* for example that tomcat
hasn't had more than 10 active committers during the past year even
though there
I've written a tiny webapp to function as a load balancer.
The way I've been using it is setting up a cluster of tomcat
servers with some webapps, and another tomcat with this load
balancer webapp in front which users access.
Are you aware of:
http://www.apache.org/~fhanik/
On Thu, 13 Nov 2003, David Graham wrote:
Is Commons a place for web applications? I've always thought it was for
small components to be used in web apps.
I agree that this doesn't feel right. Interestingly, our charter doesn't
appear to preclude this kind of thing, and there is precedent,
Intriguing idea! Although I tend to agree with the others that commons
sandbox isn't really the place for this. However, I would be VERY
interested in seeing the source! Sounds like a nifty little utility.
-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Sent:
--- Shapira, Yoav [EMAIL PROTECTED] wrote:
Howdy,
+1, and it seems like the final list was already in Senor Waldhoff's
original email...
That was the proposed list. I was just saying that people may object to
being removed and it may take a while to get to the final list.
David
Yoav
I'd like to come up with similar lists for other modules
where I'm a committer.
We've done this on James, as well. However, we consider more than CVS
commits in terms of activity. And in the one case where someone was
mistakenly listed because of a lack of CVS commits, despite being active
Howdy,
Are you aware of:
http://www.apache.org/~fhanik/
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/cluster-howto.html
Yup, and I use them. This is a bit different, in two ways:
- It's pure tomcat (or rather, pure servlet container, since there's
nothing tomcat-specific), without
I'm OK with this in principle. However, there would appear to be a bug in
the process used to determine the initial list. For example, Ted Husted
has been active quite recently:
http://marc.theaimsgroup.com/?l=jakarta-commons-devm=106502784302590w=2
Perhaps you did not take sandbox commits into
there is precedent, albeit comatose, in the sandbox 'filters'
and 'servlet' components.
Yet another set of components that are not on the Jakarta Commons
web page (http://jakarta.apache.org/commons/). Did it never occur
to anyone that projects might be comotose because no one knows
about
Is Commons a place for web applications? I've always thought
it was for small components to be used in web apps.
This, of course, begs the question of where handy little servlets
and filters should go.
there is precedent, albeit comatose, in the sandbox 'filters'
and 'servlet'
Are you aware of:
http://www.apache.org/~fhanik/
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/cluster-howto.html
Yup, and I use them. This is a bit different, in two ways:
- pure servlet container, since there's nothing tomcat-specific
How are you handling session affinity and/or
If everything were mavenized couldn't we use the multiproject plugin to
render the entire commons sandbox on its own? Default settings would
render at least a html shell for those projects that don't have a
project.xml. Or simply maintain that all sandbox components should
maintain a
+1, seems quite reasonable.
Gary
-Original Message-
From: Rodney Waldhoff [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 09:38
To: [EMAIL PROTECTED]
Subject: [PROPOSAL] emeritus committers?
There is a perception in some circles that Jakarta as a whole, and Jakarta
Howdy,
Yup, and I use them. This is a bit different, in two ways:
- pure servlet container, since there's nothing tomcat-specific
How are you handling session affinity and/or migration?
A simple way: the same rule will always redirect to the same server. So
if the load balancer's
On Thu, 13 Nov 2003, Noel J. Bergman wrote:
there is precedent, albeit comatose, in the sandbox 'filters'
and 'servlet' components.
Yet another set of components that are not on the Jakarta Commons
web page (http://jakarta.apache.org/commons/). Did it never occur
to anyone that
Rules based load balancer? Seems to me like this could need a load balancer
of its own. Have you stress tested it? I'm not saying it can't be useful
as a smart (policy based) redirector, but as a thin large scale load
balancer the Servlet lifecycle may be a little heavier than necessary. Can
Hello,
Does anyone know of a doo-dad in Commons or somewhere that would allow me to
use a .zip file (and other compressed format) as java.io.File /directory/.
What I have found so far (can't recall now) only works if your code uses a
whole framework of proxies/wrappers. Ideally, such a subclass
On Thu, 13 Nov 2003, Noel J. Bergman wrote:
We've done this on James, as well. However, we consider more than CVS
commits in terms of activity. And in the one case where someone was
mistakenly listed because of a lack of CVS commits, despite being active on
the mailing list, he complained.
Try commons-vfs
under the sandbox. You can't treat it as a java.io.File, but there
is a seperate FileObject which abstractly represents a file from any
given file system. Some of the supported filesystems include local,
jar,zip,http,ftp,cifs (windows share),etc...
Comes with a nice set of ANT
Howdy,
Rules based load balancer? Seems to me like this could need a load
balancer
of its own. Have you stress tested it? I'm not saying it can't be
useful
as a smart (policy based) redirector, but as a thin large scale load
balancer the Servlet lifecycle may be a little heavier than
On Thu, 13 Nov 2003, Shapira, Yoav wrote:
Howdy,
Actually, I'm curious to know how you obtained this list: some script
with mixed CVS commands? I'd like to come up with similar lists for
other modules where I'm a committer. I *know* for example that tomcat
hasn't had more than 10 active
AMammenT - Arun Mammen Thomas - active :) just haven't committed since being voted in
as a commiter a month+ ago.
-AMT
-Original Message-
From: Rodney Waldhoff [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 9:38 AM
To: [EMAIL PROTECTED]
Subject: [PROPOSAL] emeritus
Yup, and I use them. This is a bit different, in two ways:
- pure servlet container, since there's nothing tomcat-specific
How are you handling session affinity and/or migration?
A simple way: the same rule will always redirect to the same server.
OK. So that's one limitation compared to
On Thu, 13 Nov 2003, Rodney Waldhoff wrote:
On Thu, 13 Nov 2003, Noel J. Bergman wrote:
We've done this on James, as well. However, we consider more than CVS
commits in terms of activity. And in the one case where someone was
mistakenly listed because of a lack of CVS commits, despite
I did not take sandbox commits into account, since the sandbox is open to
any jakarta, or indeed, apache commmitter.
I.e., I was treating jakarta-commons-sandbox as a different kind of
repository.
So, so far we're moving Ted and Arun over to the active category.
On Thu, 13 Nov 2003, Martin
Ah, yes, I do recall seing this component, it quite impressive. Could a
[vsf] developer comment on the possibility of a java.io.File subclass (or
subclasses)? I'd rather not port code...
Gary
-Original Message-
From: Inger, Matthew [mailto:[EMAIL PROTECTED]
Sent: Thursday, November
Mark,
If everything were mavenized couldn't we use the multiproject plugin to
...
That is a means. I don't care about the means. I only care that it exists.
If someone wants to mavenize everything, fine. If people object because
they want everything to require only Ant, fine. I just don't
On Thu, 13 Nov 2003 14:22:16 -0500, Noel J. Bergman wrote:
Mark,
If everything were mavenized couldn't we use the multiproject
plugin
to
...
That is a means. I don't care about the means. I only care that it
exists.
If someone wants to mavenize everything, fine. If people object
Howdy,
Maybe your rules system could be factored out into a place where it
could
work with Filip's code. Don't know. Just encouraging you to talk with
Filip. :-)
I'll look into it ;)
I'm thinking that it might be a good idea to have a WebApp Commons,
either
in Commons or as a separate
--- Martin Cooper [EMAIL PROTECTED] wrote:
On Thu, 13 Nov 2003, Noel J. Bergman wrote:
there is precedent, albeit comatose, in the sandbox 'filters'
and 'servlet' components.
Yet another set of components that are not on the Jakarta Commons
web page
I'm thinking that it might be a good idea to have a WebApp Commons,
either in Commons or as a separate space. There has got to be a
lot of code that people would contribute to such as space.
I agree. So what do we need to do?
If it is going to be Jakarta Commons WebApps, then we go
Certainly, the differing build systems and websites are a problem. I'm
just not comfortable yet with the idea that I have to build all
component's sites to update a small piece of a component I'm directly
working on.
As I understand it, the proposal is to use the multi-project plug-in. I
I'm not a developer of [vfs], only a user, but having
seen the source code for the File class, it's not worth
the effort to subclass. Most people anyway make assumptions
when they see a File object (as they should). One of the
basic assumptions is that they can pass it to a FileReader
or
Dear CLI Developers,
Are you receptive to contributions from non-committers? For example:
If one sent a patch to add some minor improvement, could it conceivably get
into CVS soon? (Assuming it's a real improvement.) What baseline would you
prefer, for such a patch? jakarta-commons/cli or
FYI: I have submitted the DelimitedTokenizer class.
Could one of the committers please review this defect,
and commit the new files I have uploaded? Or, i'd be
open to being a committer myself, and just checking it
in using cvs.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL
It's only 12 days ago that the move was done.
We could redo the move and then reapply all changes since the move.
It is a little extra work but if the historical information is important it is
probably worth the effort.
-- Dirk
Mark R. Diggory wrote:
The only difficulty I have is that theres a
this would be wise, before things get too different. What would be the
best approach to tackle this?
-Mark
Dirk Verbeeck wrote:
It's only 12 days ago that the move was done.
We could redo the move and then reapply all changes since the move.
It is a little extra work but if the historical
Any help on resolving build dependencies write index.xml file is appeciated.
I just tried to build the xo component and it failed.
So even the components with an existing maven.xml will need to be updated.
PS: my point with xmlunit was about the naming conflict
-- Dirk
Inger, Matthew wrote:
I
First we should inform all math committers of course.
I will take a closer look tomorrow evening but we should undelete the files in
the sandbox, backup the proper version, do the move like you described and then
either redo all changes (including commit log) or do a simple merge.
If there are
ggregory2003/11/13 17:43:38
Modified:codec.cvsignore build.xml default.properties
Log:
Added an Ant target to zip/tar/gzip/checksum a distribution.
Revision ChangesPath
1.4 +1 -0 jakarta-commons/codec/.cvsignore
Index: .cvsignore
As previously discussed on commons-dev, we believe Commons Codec 1.2 is
ready for release.
The source for this release candidate has been tagged as CODEC_1_2_RC1 and
is available for download here:
http://cvs.apache.org/~ggregory/codec-1.2-rc1/
For more information on Commons Codec, see
mbecke 2003/11/13 18:26:16
Modified:httpclient/src/test/org/apache/commons/httpclient Tag:
HTTPCLIENT_2_0_BRANCH TestAuthenticator.java
httpclient/src/java/org/apache/commons/httpclient/auth Tag:
HTTPCLIENT_2_0_BRANCH
mbecke 2003/11/13 18:28:49
Modified:httpclient/src/test/org/apache/commons/httpclient
TestAuthenticator.java
httpclient/src/java/org/apache/commons/httpclient/auth
BasicScheme.java
Log:
Fixes basic authentication to
This is a great idea - except I think you should take the name common
out of the subproject proposal.
I'd encourage a proposal for a subproject of Jakarta - Jakarta Webapps.
This discussion should happen on Jakarta General.
Tim
On Thu, 2003-11-13 at 13:58, Noel J. Bergman wrote:
I'm
On Thu, 2003-11-13 at 13:59, Noel J. Bergman wrote:
You and Martin Cooper both favor Maven. If no one objects, would you
guys be willing to do the work? I'm a not a Maven maven. :-)
I too would favor Maven and could definately help with the transition.
OK, that's three: Mark,
On Thu, 2003-11-13 at 14:08, Noel J. Bergman wrote:
Certainly, the differing build systems and websites are a problem. I'm
just not comfortable yet with the idea that I have to build all
component's sites to update a small piece of a component I'm directly
working on.
As I understand
Unfortunately, the way I moved us out of the sandbox (Based on the
directions in the Wiki) didn't maintain historical information about the
files. I want to attempt to fix this by making some modifications in the
cvs tree. I would like to complete the following steps directly on the
cvs tree
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24699.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
There are about 16 commits that I made after move, it shouldn't be
difficult to redo these. I'll make an announcement to the group.
-Mark
Dirk Verbeeck wrote:
First we should inform all math committers of course.
I will take a closer look tomorrow evening but we should undelete the
files in
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 12, 2003 12:53 AM
To: [EMAIL PROTECTED]
Subject: [math] re: move to Apache Commons
I have always maintained
that the simple lang-like extension stuff fits in Jakarta Commons, while
the
On Thu, 13 Nov 2003, Gary Gregory wrote:
Ballot:
[X] +1 I support this release
[ ] +0 If you say so
[ ] -0 I don't think it's a good idea, but I won't stand in your way.
[ ] -1 I'm opposed
-
To unsubscribe, e-mail:
+1
On Nov 13, 2003, at 8:44 PM, Gary Gregory wrote:
As previously discussed on commons-dev, we believe Commons Codec 1.2 is
ready for release.
The source for this release candidate has been tagged as CODEC_1_2_RC1
and
is available for download here:
On Thu, 13 Nov 2003 23:26:31 -0500, Mark R. Diggory wrote:
There are about 16 commits that I made after move, it shouldn't be
difficult to redo these. I'll make an announcement to the group.
-Mark
You might try grabing the current code from commons proper and
creating a patch againt the
Different projects are going to want to update sites at different
frequencies. I think we should make an attempt to achieve
consistency
throughout the J-C sites before attempting to create a system
generate
and publish every single J-C project. Different projects change at
different
On Thu, 13 Nov 2003, Tim O'Brien wrote:
On Thu, 2003-11-13 at 14:08, Noel J. Bergman wrote:
Certainly, the differing build systems and websites are a problem. I'm
just not comfortable yet with the idea that I have to build all
component's sites to update a small piece of a component
On Thu, 13 Nov 2003 [EMAIL PROTECTED] wrote:
Different projects are going to want to update sites at different
frequencies. I think we should make an attempt to achieve
consistency
throughout the J-C sites before attempting to create a system
generate
and publish every single J-C
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24699.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24699.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi Mike,
your quick and easy patch fixes the problem right away. For my problem it
is good to go!
Thanks for the quick response and solution.
Olaf
P.S. Using UTF-8 does no good, I had tried this before.
Michael Becke [EMAIL PROTECTED] wrote on 13.11.2003 03:59:43:
Hello Olaf,
Here's a
Hello Sven,
browsers make requests in parallel for *one* user!
Meaning that all the cookies returned end up in the
same cookie store, as they do here.
A proxy servlet will make requests for different users
(browsers) and therefore has to maintain a different
state for each user. That state is
[EMAIL PROTECTED] wrote:
byte bytes[] = new byte[ (n)];
bytes = text.getBytes();
Bravo, the above code couldn't be worse...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Khalid Ishaque wrote:
When I use JDK1.4 every thing works fine, but the second I switch to JDK
1.3.1, I get the java.lang.NoClassDefFoundError:
javax/crypto/NoSuchPaddingException error. Any suggestions???
Please post the stack trace. I am sure this is coming from the
underlying SSL
[EMAIL PROTECTED] wrote:
--- Additional Comments From [EMAIL PROTECTED] 2003-11-13 03:03 ---
Created an attachment (id=9084)
Patch 1
+int[] germanChars = { 0xE4, 0x2D, 0xF6, 0x2D, 0xFc };
+StringBuffer buffer = new StringBuffer();
+for (int i = 0; i
browsers make requests in parallel for *one* user!
Meaning that all the cookies returned end up in the
same cookie store, as they do here.
A proxy servlet will make requests for different users
(browsers) and therefore has to maintain a different
state for each user. That state is typically
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24560.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24560.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hello Khalid,
My guess is that you're using NTLM authentication. NTLM require the JCE
to work. JCE is included in 1.4 JVMs but not in 1.3.1. You will need
to include the JCE jars and initialize it correctly for NTLM to work.
Mike
Ortwin Glück wrote:
Khalid Ishaque wrote:
When I use
I'm using HttpClient-2.0rc2.
I'm testing some code that makes an external URL connection. I'm
testing it with two possible URLs, but they only differ by the host name
and possibly the specified port. This is probably just a continuation
of some earlier issues I was having because of my need to
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24504.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24560.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24560.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24671.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi All,
I'd like to clarify a point about HttpClient that I do not fully
understand. How/when does the actual connection to a server close? I
understand that MultiThreadedHttpConnectionManager (and possibly
SimpleConnectionManager as well) will keep the connection alive and
reuse it for
On Wed, 2003-11-12 at 17:24, Aaron Williams wrote:
I've also recently been getting this error and was hoping someone could
shed some light on it.
We're using the RC2 version of HttpClient and our JDK versions are all
1.4 or greater. The client we are connecting to seems to have a
Verisign
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24352.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24560.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24504.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi,
it seems that releaseConnection finishes the http-download until it is
complete. I don't want that. I'm looking for a way to close the
HttpConnection if the download wasn't completed yet.
I'm aware that one cannot abort a Http-Transfer without closing the
connection and therfor loosing it
Hi Sam,
HttpClient does not do any active connection reclaiming, except when
the resources are reused. In the case of the
SimpleHttpConnectionManager the connection is never closed/reopened
unless it is required for a new method execution. The case for
MultiThreadedHttpConnectionManager is
95 matches
Mail list logo
