Is there a reason you expect it to work with commons-lang-2.0?
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Jörg Schaible [EMAIL PROTECTED] wrote on 03/12/2003
11:26:39 PM:
Just as side note: This happens with latest commons-lang-2.0 version,
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
dirkv 2003/12/07 08:09:52
Modified:jrcs .cvsignore project.properties project.xml
Added: jrcs LICENSE.txt
Removed: jrcs .classpath .project Jakarta ORO.library jrcs.jpx
LICENSE
Log:
cleanup project
Revision ChangesPath
dirkv 2003/12/07 08:10:16
Removed: jrcs/xdocs project.xml
Log:
cleanup project
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
dirkv 2003/12/07 08:11:26
Modified:jrcs/xdocs index.xml
Added: jrcs/xdocs downloads.xml navigation.xml
Log:
add navigation download
merge content from doc
Revision ChangesPath
1.2 +77 -37jakarta-commons-sandbox/jrcs/xdocs/index.xml
Index:
dirkv 2003/12/07 09:00:51
Modified:threadpool project.properties project.xml
Added: threadpool checkstyle.xml
Removed: threadpool maven.xml
Log:
cleanup project
Revision ChangesPath
1.2 +23 -15
dirkv 2003/12/07 09:01:30
Modified:threadpool/xdocs index.xml
Added: threadpool/xdocs downloads.xml navigation.xml
Log:
add navigation download
update overview
Revision ChangesPath
1.2 +22 -10jakarta-commons-sandbox/threadpool/xdocs/index.xml
dgraham 2003/12/07 09:25:01
Modified:dbutils/src/java/org/apache/commons/dbutils
BasicRowProcessor.java BasicColumnProcessor.java
ColumnProcessor.java
Log:
Moved BasicRowProcessor.mapColumnsToProperties()
to the ColumnProcessor
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=25229.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I added mapColumnsToProperties to the ColumnProcessor interface. Take a
look at the BasicRowProcessor.defaultProcessor implementation. Is there
any value to having this implementation or should we just use
BasicColumnProcessor? It seems like anyone using Oracle and number fields
needs
Okay, I tried the 'ant dist' target on my box, and of course it worked fine.
I suspect b/c I am on windows... Looking at the error, I'm guessing that it
is some sort of parsing the path that is different between Windows and
Linux.
Would it be too much of a pain for you to run the maven build and
dirkv 2003/12/07 09:50:03
Modified:compress project.xml
Log:
fix url
Revision ChangesPath
1.3 +1 -1 jakarta-commons-sandbox/compress/project.xml
Index: project.xml
===
RCS file:
On 5 Dec 2003, at 22:39, Stephen Colebourne wrote:
From what you describe, it fulfills the normal things I look for in
commons
proper promotion. If you get no problems from this mail, you should
move to
a new VOTE thread.
+1
Stephen
PS. The website could benefit from some links from the main
You could always ssh into cvs.apache.org, do a CVS checkout, build, and
see what happens...
Eric Pugh wrote:
Okay, I tried the 'ant dist' target on my box, and of course it worked fine.
I suspect b/c I am on windows... Looking at the error, I'm guessing that it
is some sort of parsing the
Does Ant and java exist on cvs.apache.org? I'm not too familiar with what
resources are available on cvs.apache.org... Could I upload a copy of
configuration to my home directory and just run ant from the ssh prompt?
Eric
-Original Message-
From: __matthewHawthorne [mailto:[EMAIL
dirkv 2003/12/07 10:58:43
Modified:events project.xml
Log:
Events component needs very up-to-date versions of
- commons-collections
- commons-collections-testframework
Revision ChangesPath
1.3 +19 -26jakarta-commons-sandbox/events/project.xml
dirkv 2003/12/07 10:59:00
Modified:events .cvsignore project.properties
Log:
cleanup project
Revision ChangesPath
1.2 +6 -0 jakarta-commons-sandbox/events/.cvsignore
Index: .cvsignore
dirkv 2003/12/07 11:00:02
Modified:events/xdocs index.xml navigation.xml
Added: events/xdocs downloads.xml
Removed: events/xdocs .cvsignore
Log:
standard website
Revision ChangesPath
1.2 +13 -11jakarta-commons-sandbox/events/xdocs/index.xml
It does not seem to be a Windows/Linux incompatibility. I checked out the
actual configuration sources on Linux, ran an 'ant dist' and the unit tests
failed with the given message.
After that I ran maven and the tests succeeded! When I ran another 'ant
dist' after that, the unit tests succeeded
epugh 2003/12/07 11:09:37
Modified:configuration/xdocs navigation.xml
configuration project.properties
Log:
Tweak site to better match other commons projects.
Revision ChangesPath
1.4 +12 -2
dirkv 2003/12/07 11:24:27
Modified:xdocs/stylesheets/menus sandbox.xml
Log:
add Compress, Events and JRCS to sandbox menu
Revision ChangesPath
1.8 +3 -0 jakarta-commons/xdocs/stylesheets/menus/sandbox.xml
Index: sandbox.xml
dirkv 2003/12/07 11:24:40
Modified:.incl_nav.xml navigation.vm
Log:
add Compress, Events and JRCS to sandbox menu
Revision ChangesPath
1.10 +3 -0 jakarta-commons/incl_nav.xml
Index: incl_nav.xml
dirkv 2003/12/07 11:24:51
Modified:.incl_nav.xml
Log:
add Compress, Events and JRCS to sandbox menu
Revision ChangesPath
1.2 +46 -80jakarta-commons-sandbox/incl_nav.xml
Index: incl_nav.xml
Ant was in my path by default (/usr/local/bin/ant)
Java 1.4 is installed in /usr/local/jdk1.4.2, you'll have to manually
set JAVA_HOME to point to this.
Eric Pugh wrote:
Does Ant and java exist on cvs.apache.org? I'm not too familiar with what
resources are available on cvs.apache.org...
dirkv 2003/12/07 11:27:41
Modified:docs beanutils.html charter.html collections.html
commons.html components.html contributors.html
dbcp.html digester.html directory.html
discovery.html el.html index.html
FYI some tabs slipped through in this commit.
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
[EMAIL PROTECTED] wrote on 08/12/2003 06:09:37 AM:
epugh 2003/12/07 11:09:37
Modified:configuration/xdocs navigation.xml
The output has to be added to the gump descriptors in the gump cvs.
http://cvs.apache.org/viewcvs.cgi/jakarta-gump/project/jakarta-commons-sandbox.xml?rev=1.149view=auto
The best way to do this is to post a request to the gump-dev mailing
list, then they can verify if the descriptor is OK.
--
dirkv 2003/12/07 13:27:06
Modified:configuration build.xml
Log:
fix ant build problems
Revision ChangesPath
1.13 +4 -4 jakarta-commons-sandbox/configuration/build.xml
Index: build.xml
===
There were 2 problems, the targetPath in the resource copy wasn't
taken into account and somehow cactus.home.tomcat4x was added to the
javadoc tag.
-- Dirk
Eric Pugh wrote:
Okay, I tried the 'ant dist' target on my box, and of course it worked fine.
I suspect b/c I am on windows... Looking
Eric, is it possible to use one of the newer websites as example?
Take commons-compress as example of the new navigation.
-- Dirk
[EMAIL PROTECTED] wrote:
epugh 2003/12/07 11:09:37
Modified:configuration/xdocs navigation.xml
configuration project.properties
Log:
hi dirk
fancy volunteering to create a document (wiki or website) describing
the latest house style for sites?
(i know that there's been a lot of talk about mavenizing the website
and it'd be nice to have easy instructions.)
- robert
On 7 Dec 2003, at 21:51, Dirk Verbeeck wrote:
Eric, is it
scolebourne2003/12/07 15:59:13
Modified:collections/data/test
IdentityMap.fullCollection.version3.obj
HashedMap.emptyCollection.version3.obj
LinkedMap.fullCollection.version3.obj
The old LRUMap ordered the elements eldest to newest in the iterator. The
new LRUMap does the opposite. Should we be sticking to the eldest first
ordering? Or is newest first a better more sensible ordering?
Stephen
-
To
I think that they probably are useful additions, however the review and
commit may take some time :-)
Stephen
- Original Message -
From: Brian McCallister [EMAIL PROTECTED]
I don't use them in a specific jakarta project (actually, now that OJB
is in db I am no longer a committer on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 7, 2003, at 7:08 PM, Stephen Colebourne wrote:
I think that they probably are useful additions, however the review and
commit may take some time :-)
No worries =) I don't have an immediate or near future need for them to
be in
I think eldest first makes more sense, based on the nature of the class.
Stephen Colebourne wrote:
The old LRUMap ordered the elements eldest to newest in the iterator. The
new LRUMap does the opposite. Should we be sticking to the eldest first
ordering? Or is newest first a better more
Phil Steitz wrote:
The links to both the legacy 1.0.2 and current (maven report)
javadocs are currently broken on the validator site. Looks like the
API docs have been moved or deleted.
Phile, Fixed, Thanks !
-
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=25264.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I am trying to use HTTPClient to connect to a WebServer that is protected by
Siteminder. The problem that I am having is that the Realm for the basic
authentication is dynamic based on the system time (to prevent users from using
the Remember my password option in a Browser). This prevents me
Hi David,
This can be accomplished by using a null realm. Please take a look at
the HttpState docs
http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/
commons/httpclient/HttpState.html for some more detail.
Mike
On Dec 7, 2003, at 3:16 PM, David Webb wrote:
I am trying to
HttpClient RC 2.0
64-bit Solaris 8
JDK 1.3.1_09
I am seeing lots of sockets in CLOSE_WAIT, despite the fact that
postMethod.releaseConnection(); is called.
This has happened so far against 2 of our ( different ) clients'
webservers, mostly to Tomcat / Coyote.
The problem with CLOSE_WAIT sockets
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.
The reason this is happening is because the releaseConnection method of
HttpMethods does not close the connection, it just returns it to the
HttpConnectionManager for reuse by another HttpMethod. A 'Connection:
Close' header tells HttpClient that this connection should be closed
after the
Saw that too ...
Having said that, I am actually not reusing an HttpClient instance, and
create a new one every time using an empty constructor ... and therefore
a new instance of SimpleHttpConnectionManager. All of this happens
inside of a method.
Now I would assume that, because my
That's relying a bit too much on garbage-collection, which can happen
at any time. You should never rely on garbage collection to clean up
native resources, like open sockets, especially if you're concerned
about such low level things as a CLOSE_WAIT state.
Thanks,
Sam
On Sunday, December
Hi John,
Yes, the problem is that releaseConnection() does not explicitly close
the connection, unless there is a Connection: close header. This is
because HttpClient makes an attempt to reuse connections where
possible. In 2.0 you have a couple of options:
- Reuse instances of
Sam Berlin wrote:
That's relying a bit too much on garbage-collection, which can happen
at any time. You should never rely on garbage collection to clean up
native resources, like open sockets, especially if you're concerned
about such low level things as a CLOSE_WAIT state.
Thanks,
Sam
Agreed. Relying on garbage collection is not really an option. There
are only 2 real choices that I can see:
1) add a method on HttpMethod to explicitly close a connection. This
would be the simplest solution, but I think it would also defeat the
purpose of connection reuse.
2) add a
On Dec 7, 2003, at 11:26 PM, Jesus M. Salvo Jr. wrote:
So bottom line is:
1) To implement HTTP/1.1 persistent connections, use a single
HttpClient instance that is reused to execute HttpMethods. Assuming of
course, that the HTTP response also does not have Connection: close,
then we have HTTP
Michael Becke wrote:
Agreed. Relying on garbage collection is not really an option.
There are only 2 real choices that I can see:
1) add a method on HttpMethod to explicitly close a connection. This
would be the simplest solution, but I think it would also defeat the
purpose of
50 matches
Mail list logo
