tobrien 2003/02/25 01:03:50
Modified:io/src/test/org/apache/commons/io/filefilter
FileFilterTestCase.java
Log:
fixed FileFilterTestCase, was not running due to a few NPEs and faulty test cases
Revision ChangesPath
1.5 +18 -12
Oh dear! What have I done... shame on me.
I'll fix that immediately. Sorry for that.
Michael Becke wrote:
I don't think this is what we want. This patch causes all connections
to be released before execution. The intent was to only release the
connection when an exception occurred and
oglueck 2003/02/25 01:13:56
Modified:httpclient/src/java/org/apache/commons/httpclient
HttpClient.java
Log:
backing out my erronous patch
Revision ChangesPath
1.71 +13 -8
tobrien 2003/02/25 01:39:38
Modified:io/src/test/org/apache/commons/io/filefilter
FileFilterTestCase.java
Log:
oops, file filter test case, directory-filter tests for non-existent directory
'test' now fixed
Revision ChangesPath
1.6 +5 -5
tobrien 2003/02/25 01:56:28
Modified:io/src/test/org/apache/commons/io/filefilter
FileFilterTestCase.java
Log:
TTesting the DirectoryFileFilter against a non-existent directory
of the name test was causing problems due to the fact that another
TestCase
The Tar test cases are failing for me on both a Linux 7.1 and on a Windows
XP box.
[junit] Testcase:
testReadPosixTar(org.apache.commons.io.compress.tar.TarTestCase): FAILED
[junit] Entry size expected:652 but was:666
[junit] junit.framework.AssertionFailedError:
digester 1.4.1 is a bug fix release.
i've created release candidate distributions which can be found at:
http://cvs.apache.org/~rdonkin/commons-digester/RC1/
your votes, please:
Release Digester 1.4.1
-
[ ] +1 I support this release and will help
[ ] +0
+1, this release might also be a good time to get rid of this legacy site:
http://jakarta.apache.org/commons/digester/, and add a redirect to
http://jakarta.apache.org/commons/digester.html. I'd be willing to help out
with this.
- tim
-Original Message-
From: robert burrell donkin
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=17043.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Tuesday, February 25, 2003, at 12:09 AM, Erik Tennant wrote:
For my needs, that sounds sufficient. Any ETA on when someone might be
looking at this?
i'll probably be looking at this pretty soon. since this is a big change i'
ll probably post to the list explaining the changes first.
I'm more
On Tue, 25 Feb 2003, O'brien, Tim wrote:
Date: Tue, 25 Feb 2003 13:26:04 -0600
From: O'brien, Tim [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED]
To: 'Jakarta Commons Developers List' [EMAIL PROTECTED]
Subject: RE: [VOTE][digester] Release Digester 1.4.1
+1,
On Tue, 25 Feb 2003, Craig R. McClanahan wrote:
On Tue, 25 Feb 2003, O'brien, Tim wrote:
Date: Tue, 25 Feb 2003 13:26:04 -0600
From: O'brien, Tim [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED]
To: 'Jakarta Commons Developers List' [EMAIL PROTECTED]
beanutils has a fair number of utility classes which are composed of
static methods. i'd like to create proper beans containing the
implementation code and have the static methods call an instance.
this would allow users to create different instances with - for example -
different registered
rwaldhoff2003/02/25 14:52:33
Modified:pool .cvsignore project.xml
Added: pool project.properties
Log:
* add project.properties, update project.xml for better maven support
* ignore maven's target directory, and some eclipse-specific files
Revision Changes
jstrachan2003/02/25 14:54:23
Modified:jelly/jelly-tags/bean/src/java/org/apache/commons/jelly/tags/bean
BeanTagLibrary.java BeandefTag.java BeanTag.java
BeanPropertyTag.java
rwaldhoff2003/02/25 14:56:55
Modified:pool .cvsignore
Log:
ignore maven.log, velocity.log
Revision ChangesPath
1.4 +2 -0 jakarta-commons/pool/.cvsignore
Index: .cvsignore
===
RCS
On Tue, 25 Feb 2003, robert burrell donkin wrote:
Date: Tue, 25 Feb 2003 22:45:16 +
From: robert burrell donkin [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Subject: [beanutils] beans for static
jstrachan2003/02/25 15:26:15
Added: jelly/src/test/org/apache/commons/jelly/core
testInvokeStaticTag.jelly TestInvokeStaticTag.java
Log:
Applied patch submitted by Robert McIntosh to help unit test the static invoke tags
Revision ChangesPath
1.1
From: Robert McIntosh [EMAIL PROTECTED]
Here is the JUnit test class and test script for the InvokeStaticTag.
And yep, I ran it :-)
Thanks Robert - patch committed.
James
---
http://radio.weblogs.com/0112098/
__
Do You Yahoo!?
Everything
rwaldhoff2003/02/25 15:38:22
Modified:pool/src/java/org/apache/commons/pool
BaseKeyedObjectPool.java BaseObjectPool.java
KeyedPoolableObjectFactory.java
Log:
some cleanup, remove deprecated methods
Revision ChangesPath
1.5
I'm attempting to download the commons sandbox package VFS. The link
provided (http://gump.covalent.net/jars/latest/commons-vfs/) on the
project download page
(http://jakarta.apache.org/commons/sandbox/vfs/download.html) does not
point to a live server. This is the second time in as many days
rwaldhoff2003/02/25 16:35:19
Modified:collections/src/test/org/apache/commons/collections
TestObject.java
Log:
some cleanup, re-org methods, reduce scope on some
Revision ChangesPath
1.19 +140 -125
I have fixed the link on the download page. Try it again.
On Wed, 26 Feb 2003 12:01 am, Steve McKay wrote:
I'm attempting to download the commons sandbox package VFS. The link
provided (http://gump.covalent.net/jars/latest/commons-vfs/) on the
project download page
rwaldhoff2003/02/25 17:33:22
Modified:collections maven.xml
collections/src/test/org/apache/commons/collections
TestList.java TestMap.java TestObject.java
collections/src/test/org/apache/commons/collections/comparators
hmm looks like the ant script uses jjar to download what is needed...
any way to build from behind a firewall? http proxy is supported only.
Adam Murdoch wrote:
I have fixed the link on the download page. Try it again.
On Wed, 26 Feb 2003 12:01 am, Steve McKay wrote:
I'm attempting to
dmitri 2003/02/25 17:45:01
Modified:jxpath STATUS.html project.xml
jxpath/src/java/org/apache/commons/jxpath/ri/model/dynamic
DynamicPropertyPointer.java
jxpath/xdocs release-notes-1.1.xml
jxpath/xdocs/stylesheets
rwaldhoff2003/02/25 17:45:53
Modified:collections project.xml
Added: collections project.properties
Log:
make maven clover work
Revision ChangesPath
1.10 +5 -0 jakarta-commons/collections/project.xml
Index: project.xml
mbecke 2003/02/25 15:33:48
Modified:httpclient/src/test-webapp/src/org/apache/commons/httpclient
RedirectServlet.java WriteCookieServlet.java
MultiMethodServlet.java StatusLineServlet.java
RequestBodyServlet.java
On Tue, 25 Feb 2003, Steve McKay wrote:
Date: Tue, 25 Feb 2003 16:01:57 -0800
From: Steve McKay [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [VFS] - Download link broken?
I'm attempting to download the commons sandbox
Any comparisons on VFS vs JNDI? seems very similar to me.
--
=
= Management is doing things right; leadership is doing the =
= right things.- Peter Drucker=
You can use maven to build. It can download dependencies via a proxy (if you
configure it to).
Alternatively, you can tell ant where the proxy is by setting some properties
when running it:
ant -Dhttp.proxyHost=host ...
The properties you may need to set:
http.proxyHost
http.proxyPort
Adam Murdoch wrote:
I have fixed the link on the download page. Try it again.
Thanks. And thanks for the dependancy list--always nice.
--
Steve McKay
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
mbecke 2003/02/25 18:33:15
Modified:httpclient/src/java/org/apache/commons/httpclient/methods/multipart
FilePart.java
Log:
FilePartSource input stream is now closed after writing.
PR: 17409
Revision ChangesPath
1.13 +6 -3
On Wed, 26 Feb 2003 02:17 am, Hanasaki JiJi wrote:
Any comparisons on VFS vs JNDI? seems very similar to me.
They are very similar. JNDI is a little more general: a namespace of Objects.
VFS is a little more specific: a hierarchy of files.
VFS does not try to be as universal as JNDI does,
Thinking out loud here What do you think?
1. turn the VFS providers into JNDI SPI
2. implement VFS via JNDI or the JNDI SPI's directly
Adam Murdoch wrote:
On Wed, 26 Feb 2003 02:17 am, Hanasaki JiJi wrote:
Any comparisons on VFS vs JNDI? seems very similar to me.
They are very similar.
-Original Message-
From: Henri Yandell [mailto:[EMAIL PROTECTED]
On Tue, 25 Feb 2003, Craig R. McClanahan wrote:
Isn't digester.html the *old* site, and don't we want the new
(Maven-based) one?
That's what I thought, except the maven-based one is now out
of date, only
Hanasaki JiJi wrote:
Thinking out loud here What do you think?
1. turn the VFS providers into JNDI SPI
2. implement VFS via JNDI or the JNDI SPI's directly
+1
Tomcat abstracts the file system using JNDI - it may be worth taking
a look. That means any JNDI based VFS would be easy to
Adam Murdoch wrote:
On Wed, 26 Feb 2003 02:17 am, Hanasaki JiJi wrote:
Any comparisons on VFS vs JNDI? seems very similar to me.
They are very similar. JNDI is a little more general: a namespace of
Objects. VFS is a little more specific: a hierarchy of files.
The namespace of Objects is
This is an intermediate alpha release. The build process used in the
previous Alpha 2 changed from generating 4 build artifacts to a single
distribution. This one zip contains everything: all the source, the
binary jar, the logging dependancy, generated javadoc and required build
files for Ant
Simon
I'd really appreciate it if you could send us the debug trace for
analysis. Please refer to the following url for instructions on how wire
log can be activated:
http://jakarta.apache.org/commons/httpclient/logging.html
Your problem should be easily solvable by disabling 100-continue
Aurelien,
Same request. Could you please produce a wire log of the HTTP
communication that causes the problem you mentioned?
Oleg
On Tue, 2003-02-25 at 11:17, Aurelien Pernoud wrote:
Hey that may be the trouble I'm meeting too and I assumed it to be related
to
Sure, I'll try to reproduce it with wire log, as it doesn't happen on every
request :((
Oleg Kalnichevski a écrit :
Aurelien,
Same request. Could you please produce a wire log of the HTTP
communication that causes the problem you mentioned?
Oleg
I'm sorry I have trouble enabling wire log within my webapp. I'm using
Turbine and in fact it seems HttpClient took the setting from turbine to log
it's info.
I can't find an easy way to enable wirelog in a specific file... I'm not
used to commons logging.
Aurelien Pernoud a écrit :
Sure,
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=13463.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Here is stuff I got from a Post Method, after removing the log of method :
[25 févr. 2003 16:05:31 DEBUG] - User-Agent: Jakarta
Commons-HttpClient/2.0alpha2
[\r\n]
[25 févr. 2003 16:05:31 DEBUG] - Host: localhost:8080
[\r\n]
[25 févr. 2003 16:05:31 DEBUG] - Cookie: $Version=0;
Hopefully the last release candidate for alpha3, rc4, is ready:
http://jakarta.apache.org/builds/jakarta-commons/release/commons-httpclient/v2.0
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
I'm using Tomcat 4.1.18, and my log for Turbine is set to debug (not that
crazy ;)), but httpclient is either logging everything, either nothing...
very weird. I'll have to look further into it sometime.
What you say is weird, I have another line where my post went ok :
Oleg Kalnichevski a
Sorry the fiest mail went out too soon...
I'm using Tomcat 4.1.18, and my log for Turbine is set to debug (not that
crazy ;)), but httpclient is either logging everything, either nothing...
very weird. I'll have to look further into it sometime.
What you say is weird (to me), I have another
Aurelien,
Something is fishy about your setup. I have developed 100-continue
handshake support for HttpClient using Tomcat 4.1.18. It does handle
100-continue correctly. I may need to see the complete log of yours in
order to figure out what is going on there. The only theory I can come
up with at
Oleg Kalnichevski a écrit :
Aurelien,
Something is fishy about your setup. I have developed 100-continue
handshake support for HttpClient using Tomcat 4.1.18. It does handle
100-continue correctly. I may need to see the complete log of yours in
order to figure out what is going on there.
Ok I'll try it without the Expect: header tomorrow. But what I can surely
say is that I didn't stress Tomcat, I was alone making single requests on
it, not even simultaneously. Of course the logging did stress a little, as
it logged like 4MB in 30 seconds...
I've attached a log more precise on
What is moreover a trouble is that the connection wasn't released after the
failed post. Indeed as I call method.releaseConnection() and that response
Inputstream is empty, I didn't see anything like
HttpConnectionManager.releaseConnection: Release connection for
[EMAIL PROTECTED]
after that
+1
Jeffrey Dever wrote:
Propose to promote the current 2.0 Alpha 3 release candidate 4 to the
offical release of 2.0 Alpha 3. The next release will be 2.0 Beta 1
which will commence after all Beta 1 targeted bugs are closed.
+1 yes
+/- 0 abstain
-1 no
Folks
I am currently working on a patch enabling HttpClient to handle
cross-site redirects.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16729
In order to lay foundation for this capability I needed to make quite a
few changes to HttpClient HttpMethodBase. I have opted for a more
Simon
Please try these settings. This should prompt commons-logging to use
SimpleLog instead of Log4J, which does not support TRACE verbosity.
-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog
-Dorg.apache.commons.logging.simplelog.log.httpclient.wire=debug
We are now back in the Beta 1 development phase. There are currently 14
outstanding issues to tackle before we can drop another release. Work is
going extremely well. Great thanks to everyone that was involved!
We should be addressing the beta 1 bugs before other issues. I think
that we can
Completely agree. A few months ago we have been discussing possibility
of splitting HttpMethod into HttpRequest/HttpResponse pair once we get
2.0 is released. I would wait with more radical changes till then
Cheers
Oleg
On Tue, 2003-02-25 at 21:38, Sam Maloney wrote:
Makes sense to me,
I
I definitely think this is a good idea. HttpMethodBase is too big. I'm
wondering if this is too much of a change for 2.0 though. It will
require quite a few changes for users.
On a related note, when you implement the redirection handling I would
suggest removing the use of the URL class.
Mike
I share your concerns, but the work on it has been blessed by Jandalf.
Besides, I see no way of providing cross-site redirects while
maintaining full compatibility with the existing HttpClient.
Important question. Do you think that the patch will play well with your
connection pooling stuff?
Attached is a log of my application (log4j, with most of the
HttpConnection.isResponseAvaliable messages removed)
BTW: typo in method name
The interesting bit is that it times out (3 seconds) rather than getting the
100-continue response. Then, after it has send the body, the 100-continue
Did Oleg's work on the redirect made it to alpha3 rc4?
Oleg Kalnichevski wrote:
Folks
I was going to start working on it today. If there are any other takers,
please let me know
Cheers
Oleg
On Mon, 2003-02-24 at 07:27, Jeffrey Dever wrote:
This is currently on the todo list. Refer to the
Oleg,
Great that you are taking on this work. I have both general and
specific comments.
General:
* I share other's concerns with restructuring too much. At the risk
of causing you much pain (since I'm not the one implementing!),
how about the following: Create a new interface
No. Its still preliminary.
Jesus M. Salvo Jr. wrote:
Did Oleg's work on the redirect made it to alpha3 rc4?
Oleg Kalnichevski wrote:
Folks
I was going to start working on it today. If there are any other takers,
please let me know
Cheers
Oleg
On Mon, 2003-02-24 at 07:27, Jeffrey Dever
Michael Becke wrote:
I think it would be possible to add cross site redirects at the
HttpClient level without removing the other functionality from the
HttpMethod. HttpClient would just need to check the status code and
re-try. But, just because it is possible doesn't mean we should do
it.
I'm using a MultipartPostMethod to upload a file to a servlet:
File file = new File(strUrl);
HttpClient client = new HttpClient();
HostConfiguration hostConfig = new HostConfiguration();
MultipartPostMethod mpPost = new MultipartPostMethod();
hostConfig.setHost(someURL.getHost(),
As I mentioned in a previous posting (Subject: MultipartPostMethod Holding File Stream
Open?), I'm using the MultipartPostMethod to upload a file to a servlet. Here is the
example code that I included in the other posting:
File file = new File(strUrl);
HttpClient client = new HttpClient();
To implement this feature (full redirects), there are really only three
general choices that make sense:
1) augment HttpMethodBase.execute()
Pros: current functionality is maintained
Cons: makes complex code more complex,
2) have two stage redirection done partially in HttpMethodBase and part
This is an intermediate alpha release. The build process used in the
previous Alpha 2 changed from generating 4 build artifacts to a single
distribution. This one zip contains everything: all the source, the
binary jar, the logging dependancy, generated javadoc and required build
files for Ant
68 matches
Mail list logo
