rdonkin 2003/03/02 03:13:05
Modified:xdocscomponents.xml digester.xml
Log:
Update to reflect digseter 1.4.1 release
Revision ChangesPath
1.77 +3 -5 jakarta-commons/xdocs/components.xml
Index: components.xml
rdonkin 2003/03/02 03:13:30
Modified:docs components.html digester.html
Log:
Update to reflect digseter 1.4.1 release
Revision ChangesPath
1.92 +3 -5 jakarta-commons/docs/components.html
Index: components.html
The Commons Team is pleased to announce that Digester 1.4.1 from the
Apache Software Foundation has been released.
Digester is a powerful, flexible, SAX-based xml-object mapper. A typical
use case is parsing xml configuration files.
This is a bug fix release. For more details see
rdonkin 2003/03/02 03:33:49
Modified:digester STATUS.html build.xml
Log:
Post 1.4.1 release update
Revision ChangesPath
1.8 +3 -3 jakarta-commons/digester/STATUS.html
Index: STATUS.html
===
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=12997.
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=13098.
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=16785.
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=16350.
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=16413.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi folks,
Can we consider one of two solutions for this _single_ use of commons
logging
1) Removal of the commons-logging from attributes?
2) Backwards compatible rework that will allow the application to run
without commons logging in the classpath (or classloader tree for
complex
scohen 2003/03/02 09:53:01
jakarta-commons/net/src/test/org/apache/commons/net/ftp/parser - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
scohen 2003/03/02 09:58:28
jakarta-commons/net/src/java/org/apache/commons/net/ftp/parser - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
scohen 2003/03/02 10:15:24
Modified:net/src/java/org/apache/commons/net/ftp FTPClient.java
Added: net/src/java/org/apache/commons/net/ftp
FTPFileEntryParser.java FTPFileIterator.java
FTPFileList.java FTPFileListParserImpl.java
Hi,
Hi folks,
Can we consider one of two solutions for this _single_ use of commons
logging
1) Removal of the commons-logging from attributes?
2) Backwards compatible rework that will allow the application to run
without commons logging in the classpath (or classloader tree for
complex
scohen 2003/03/02 10:18:24
Added: net/src/java/org/apache/commons/net/ftp/parser
EnterpriseUnixFTPEntryParser.java
NTFTPEntryParser.java OS2FTPEntryParser.java
UnixFTPEntryParser.java VMSFTPEntryParser.java
scohen 2003/03/02 10:22:05
Modified:net project.xml
Log:
add dependency for oro jar
Revision ChangesPath
1.23 +6 -1 jakarta-commons/net/project.xml
Index: project.xml
===
RCS file:
scohen 2003/03/02 10:22:24
Modified:net build.xml
Log:
add dependency for oro jar
Revision ChangesPath
1.16 +6 -4 jakarta-commons/net/build.xml
Index: build.xml
===
RCS file:
scohen 2003/03/02 10:27:41
Added: net/src/test/org/apache/commons/net/ftp/parser
EnterpriseUnixFTPEntryParserTest.java
FTPParseTestFramework.java
NTFTPEntryParserTest.java
I have checked in code implementing the new FTPFileEntryParser system, that has been
knocking around for close to a year. This code basically allows an iterable list of
ftp entries to created from which more expensive FTPFile objects are not created until
they are needed. It also checks in a
Can we consider one of two solutions for this _single_ use of commons
logging
1) Removal of the commons-logging from attributes?
2) Backwards compatible rework that will allow the application to run
without commons logging in the classpath (or classloader tree for
complex
Juozas,
Can we consider one of two solutions for this _single_ use of commons
logging
1) Removal of the commons-logging from attributes?
2) Backwards compatible rework that will allow the application to run
without commons logging in the classpath (or classloader tree for
complex deployments).
scohen 2003/03/02 11:36:44
Modified:net/proposal/ftp2/src/java/org/apache/commons/net/ftp/ftp2
FTPClient2.java FTPFileEntryParser.java
FTPFileIterator.java FTPFileList.java
scohen 2003/03/02 11:47:00
Modified:net/proposal/ftp2/src/test/org/apache/commons/net/ftp/ftp2/parser
NTFTPEntryParserTest.java
OS2FTPEntryParserTest.java
UnixFTPEntryParserTest.java
snip
Why does people get in to trouble when depending on ThreadContext
classloader which is
the correct way to load classes with (if one want to be container friendly
:)
Depending on ThreadContext classloader will work if the container follows
the spec - and if there
are no TCL, then use
Juozas,
Why does people get in to trouble when depending on ThreadContext
classloader which is
the correct way to load classes with (if one want to be container friendly
:)
Depending on ThreadContext classloader will work if the container follows
the spec - and if there
are no TCL, then use
mbecke 2003/03/02 15:22:44
Added: httpclient/src/examples MultiThreadedExample.java
Log:
Initial checkin. Added an example that performs GETs from muliple threads.
Revision ChangesPath
1.1
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=17470.
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=17470.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
tobrien 2003/03/02 17:07:03
Modified:xdocs/stylesheets project.xml
Log:
Changed reference to Codec
Revision ChangesPath
1.68 +1 -1 jakarta-commons/xdocs/stylesheets/project.xml
Index: project.xml
tobrien 2003/03/02 17:49:34
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
tobrien 2003/03/02 17:54:10
Modified:xdocscomponents.xml
Log:
updated reference to codec
Revision ChangesPath
1.78 +1 -1 jakarta-commons/xdocs/components.xml
Index: components.xml
===
tobrien 2003/03/02 17:55:07
Modified:docs components.html
Log:
updated reference to codec
Revision ChangesPath
1.94 +1 -1 jakarta-commons/docs/components.html
Index: components.html
===
tobrien 2003/03/02 17:56:21
Modified:codec/xdocs/images logo.jpg
Log:
Updated the Codec logo
Revision ChangesPath
1.2 +41 -95jakarta-commons-sandbox/codec/xdocs/images/logo.jpg
Binary file
tobrien 2003/03/02 17:56:47
Modified:codec/xdocs index.xml navigation.xml
Added: codec/xdocs changes.xml
Log:
Updated codec site
Revision ChangesPath
1.2 +4 -1 jakarta-commons-sandbox/codec/xdocs/index.xml
Index: index.xml
tobrien 2003/03/02 17:57:27
Modified:codecproject.xml project.properties
Log:
Updated maven project descriptor and associated properties
Revision ChangesPath
1.2 +43 -8 jakarta-commons-sandbox/codec/project.xml
Index: project.xml
tobrien 2003/03/02 17:58:08
Modified:codec/src/java/org/apache/commons/codec/binary Base64.java
codec/src/java/org/apache/commons/codec/language
DoubleMetaphone.java Nysiis.java
Log:
Added todo items to classes
Revision ChangesPath
tobrien 2003/03/02 17:59:11
Modified:codecTODO
Log:
TODO now only contains project-wide todo items. Code specific items have been moved
to the corresponding classes and are made available via the maven-tasklist-plugin.
Completed items are now displayed via the
scohen 2003/03/02 19:42:06
Modified:net/src/java/org/apache/commons/net/ftp
FTPFileEntryParser.java FTPFileIterator.java
FTPFileList.java
Log:
remove stale @see references from javadocs
Revision ChangesPath
1.3 +2 -2
I'm partially responsible for the current classloading scheme. I'd sure
like to understand what your problems are. Can you describe a
step-by-step scenario that demonstrates what you see happening, and why
you think it's not correct?
Likewise, for any code changes that you make, please help
I am getting inconsistent results on a few things and I realized I really am
sort of parroting examples and really don't know the true order of things
when doing a series of connections. So let me ask a few questions:
1) If doing to of the same type of requests what is the correct method for
I had a new problem today, but unlike my last one, I figured it out today.
But I was wondering if it the way the HttpClient works, a setting, or
something I should be doing.
The HttpClient is creating a header like this:
Cookie: cookie1=blah1
Cookie: cookie2=blah2
Cookie: cookie3-blah3
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=17569.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Ross,
Just use strict mode. That will make HttpClient put all cookies into one
header
Oleg
On Sun, 2003-03-02 at 21:38, Ross Rankin wrote:
I had a new problem today, but unlike my last one, I figured it out today.
But I was wondering if it the way the HttpClient works, a setting, or
something
Ross Rankin wrote:
I am getting inconsistent results on a few things and I realized I really am
sort of parroting examples and really don't know the true order of things
when doing a series of connections. So let me ask a few questions:
What sorts of inconsistent results?
1) If doing to of the
Ross,
Below are some answers to your questions.
1) If doing to of the same type of requests what is the correct
method for
they type of action do I:
a) use two Method variables
b) use the same one with a recycle but cast it new again
c) use the same one without a recycle
45 matches
Mail list logo
