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=16525.
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=16525.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
From: robert burrell donkin [EMAIL PROTECTED]
the release candidate can be found at
http://cvs.apache.org/~rdonkin/commons-digester/RC1/
your votes, please:
Digester 1.4 Release
-
[X] +1 I support this release and will help
[ ] +0 I support
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=16600.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
tobrien 2003/02/03 06:12:17
jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/language - New
directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Title: RE: cvs commit: jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/language - New directory
Please remove me from the mailing list
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 03, 2003 8:12 AM
To: [EMAIL PROTECTED]
mvdb2003/02/03 06:23:31
Modified:betwixt/src/java/org/apache/commons/betwixt/digester
XMLIntrospectorHelper.java
Log:
Fixing nullpointer exception scenario when debugging.
Revision ChangesPath
1.17 +3 -2
On Mon, Feb 03, 2003 at 09:49:04AM +0100, Martin van den Bemt wrote:
So maybe there should be an xml:text tag to get this handled (don't use
xslt myself though) ?
I think it's better to have a jsl:text tag that accepts the
disable-output-escaping=yes attribute. You don't need any special
xml
tobrien 2003/02/03 06:58:55
jakarta-commons-sandbox/codec/src/test/org/apache/commons/codec/language - New
directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
tobrien 2003/02/03 07:00:12
Modified:codec/src/test/org/apache/commons/codec TestAll.java
Added: codecTODO
codec/src/java/org/apache/commons/codec/language
DoubleMetaphone.java
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=13676.
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=16440.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
tobrien 2003/02/03 07:48:14
Modified:codecTODO
codec/src/test/org/apache/commons/codec TestAll.java
Added: codec/src/java/org/apache/commons/codec/language Nysiis.java
codec/src/test/org/apache/commons/codec/language
DoubleMetaphone and Nysiis have been committed.
Kyle, thanks for the code.
Here's a numbered list...
1. Thread Safety - All of the other encoders are thread safe in that
multiple threads can call encode on a single instance of the class.
Since we intend codec to be in wide use, it might
bayard 2003/02/03 08:02:17
Modified:codec/src/java/org/apache/commons/codec/language Nysiis.java
Log:
Fixed licence from Turbine to Commons.
Revision ChangesPath
1.2 +2 -2
jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/language/Nysiis.java
bayard 2003/02/03 08:03:54
Modified:codec/src/java/org/apache/commons/codec Encoder.java
EncoderComparator.java Metaphone.java
RefinedSoundex.java Soundex.java
codec/src/java/org/apache/commons/codec/language
Big worry for code like this is to make sure the licencing etc is okay. As
even the cvs-sandbox is published code, making sure that the ASF are not
taking over ownership of code without permission is important.
These seem okay. Nysiis and DoubleMetaphone are names of algorithms and
not
Title: RE: cvs commit: jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/language DoubleMetaphone.java
Please remove me from the mailing list - [EMAIL PROTECTED]
This is my second week with e-mail bombardment.
The documentation to remove yourself from the e-mail list is not
DoubleMetaphone also seems to be a port of CPAN Test-DoubleMetaphone-0.05.
So, I think both of Kyle's contributions are covered under artistic license.
I believe that Perl Artistic section 3a covers this:
http://www.perl.com/pub/a/language/misc/Artistic.html, but in big bold red
letters, I am
Rev 1.1 of Base64 was checked in by Sander Striker about 1 year ago. It was
initially from the HttpClient project.
The codec Base64 class has an open bug which also should point us in the
right direction: http://issues.apache.org/bugzilla/show_bug.cgi?id=16440
So, I'll make a proposal and hope
Hi,
This pertains to primarily to James and Daniel but I would like to move
the commons-sql package over to db.apache.org. I'm in the process of
moving OJB and Torque over there so this is the next set of code I want
to move.
Any objections?
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
Hello,
I dug through the code to see why my redirects were not being followed.
I found HttpMethodBase:checkValidRedirect was not honoring cross server
redirects. Isn't this a common type of redirect? Is there a reason its
not supported? I did a lot of digging in the specs and couldn't find
+1
Any timeline for raising codec out of the sandbox?
O'brien, Tim wrote:
Rev 1.1 of Base64 was checked in by Sander Striker about 1 year ago. It was
initially from the HttpClient project.
The codec Base64 class has an open bug which also should point us in the
right direction:
It might need a little time for Tim to get things sorted out.
It's all a bit messy in there.
I guess the question needs to be whether it should focus on new
functionalities or wrapping up enough to goto Commons-proper.
Hen
On Mon, 3 Feb 2003, Jeffrey Dever wrote:
+1
Any timeline for
Hi Rod,
I'm +1 on moving [EL] to commons proper, but -1 on promoting components
this casually. If this is meant to be a binding vote on promoting EL, it
ought to be on a [VOTE] thread, and include a proposal that identif[ies]
the rationale for the package, its scope, its interaction with
+1
Maybe chunked transfer encoding and URL encoding would fit into this
package as well somehow?
Odi
O'brien, Tim wrote:
Rev 1.1 of Base64 was checked in by Sander Striker about 1 year ago. It was
initially from the HttpClient project.
The codec Base64 class has an open bug which also should
Basically you contribute to an ASF project via patches and general
efforts on the mailing lists. Another way is to help with testing
pre-releases.
See: http://jakarta.apache.org/site/getinvolved.html
Hen
On Mon, 3 Feb 2003, Winston Ojeda wrote:
Don't know, but if you find out let me know.
URI, URL, and URNs are very general - and used everywhere in ASF - this
sounds like prime content for the Apache Commons. I don't think that
[codec] is the appropriate place for UR[LIN] code, but maybe chunked
transfer encoding.
I think this is even more general than networks, go to the ISOC,
rdonkin 2003/02/03 09:57:23
Modified:fileupload STATUS.html
Log:
Added myself to the committers list since i'll be doing some work on the docs
Revision ChangesPath
1.6 +2 -1 jakarta-commons/fileupload/STATUS.html
Index: STATUS.html
jstrachan2003/02/03 09:58:00
Modified:jelly/jelly-tags/jms/src/java/org/apache/commons/jelly/tags/jms
OnMessageTag.java
Log:
Patched mistake in jms:onMessage tag which was incorrectly settting the context,
rather than the message as a variable when a Message
rdonkin 2003/02/03 09:58:31
Modified:fileupload project.xml
fileupload/xdocs index.xml
Added: fileupload/xdocs navigation.xml overview.xml tasks.xml
Log:
Created a basic maven documentation.
Revision ChangesPath
1.13 +6 -0
I'm +1 to commons-uri.
As Tim points out, it's not just URLs, so we could even have pieces of
code for dealing with ISBNs etc if the need arose.
I don't think they really tie well to commons-io, and losing them in
commons-net would be a mistake probably.
Hen
On Mon, 3 Feb 2003, O'brien, Tim
On Mon, Feb 03, 2003 at 10:46:23AM -0600, O'brien, Tim wrote:
Rev 1.1 of Base64 was checked in by Sander Striker about 1 year ago. It was
initially from the HttpClient project.
The codec Base64 class has an open bug which also should point us in the
right direction:
Well, I have been contributing patches both to ant for over a year and
commons-net since it came under jakarta.
-Original Message-
From: Henri Yandell [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 03, 2003 11:56 AM
To: Jakarta Commons Developers List
Subject: RE: [net] Refactoring of
My apologies, Scott, my apologies.
Tim O'Brien
-Original Message-
From: Scott Sanders [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 03, 2003 11:58 AM
To: Jakarta Commons Developers List
Subject: Re: [codec] RE: more common classes need a home
On Mon, Feb 03, 2003
The most recent dicsussion of having a commons-vote list had pretty good
support but the thread died away.
Not having a dedicated place to vote is a continuous problem for
HttpClient, and would be for any other project that is looking towards
its own list. When we vote, we have to decide:
Sounds good to me.
Whenever db.apache.org is ready, I'd be only too happy to move dbutils
over.
Hen
On Mon, 3 Feb 2003 [EMAIL PROTECTED] wrote:
Not that I'm a committer to it, but commons-dbutils might also seem an appropriate
move if there is to be a db-commons.
Stephen
from:
From: Incze Lajos [EMAIL PROTECTED]
On Mon, Feb 03, 2003 at 09:49:04AM +0100, Martin van den Bemt wrote:
So maybe there should be an xml:text tag to get this handled (don't use
xslt myself though) ?
I think it's better to have a jsl:text tag that accepts the
disable-output-escaping=yes
the following concerns me about the proposal:
(4) Initial Committers
The initial committers will be identical to those of the Standard Taglib
project.
i'm unhappy with this since it implies that all current taglib committers
will be grandfathered in. a list of the people being proposed would
There seems to be a few possibilities here. One is that the XML output uses
a DTD (internal or external) and you wish to output an entity reference in
the output. i.e. the output contains a DOCTYPE and an entity reference to an
entity defined in this DOCTYPE.
Another option could be that the
+1
- robert
On Monday, February 3, 2003, at 06:12 PM, Jeffrey Dever wrote:
The most recent dicsussion of having a commons-vote list had pretty good
support but the thread died away.
Not having a dedicated place to vote is a continuous problem for
HttpClient, and would be for any other
Seems like your attachment got stripped from the mail. Amybe wrong
extension or too big, don't know..
Mvgr,
Martin
On Mon, 2003-02-03 at 19:22, LOX wrote:
I'm sorry, I'm relly new to the Apache lists..
Could somebody explain me what happened?
First I sent a mail containing the patch, a
now that codec has come alive again, anyone feel like volunteering to
write something up about codec and the future plans for the january news
letter?
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
luehe 2003/02/03 10:35:56
Modified:el PROPOSAL.html
Log:
updated list of initial committers
Revision ChangesPath
1.2 +10 -4 jakarta-commons-sandbox/el/PROPOSAL.html
Index: PROPOSAL.html
rdonkin 2003/02/03 10:40:28
Modified:digester RELEASE-NOTES.txt build.xml
Log:
Preparations for digester 1.4 release
Revision ChangesPath
1.8 +23 -9 jakarta-commons/digester/RELEASE-NOTES.txt
Index: RELEASE-NOTES.txt
Robert,
(4) Initial Committers
The initial committers will be identical to those of the Standard Taglib
project.
i'm unhappy with this since it implies that all current taglib committers
will be grandfathered in. a list of the people being proposed would be
much better.
OK, I've set
On Mon, 3 Feb 2003, robert burrell donkin wrote:
Date: Mon, 3 Feb 2003 17:43:22 +
From: robert burrell donkin [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Subject: [beanutils] 1.6.1 release? [WAS Re:
-1 on a voting list separate from the DEV list for a given project.
There are two main reasons for my view on this:
* People who search the DEV mailing list archives should be
able to see both the discussions around design decisions
and the votes with a single search; making them look two
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=16732.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Anyone interested in reading a draft, should switch over to general@jakarta
list. I'll write a quick draft.
Tim O'Brien
-Original Message-
From: robert burrell donkin
[mailto:[EMAIL PROTECTED]]
Sent: Monday, February 03, 2003 12:34 PM
To: 'Jakarta Commons Developers
I've a CSVReader, CSVWriter, and POI versions [well poi reader yet to be
written].
Would these go better in codec or io or not really fitting for Jakarta??
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Have a go with the txt extension (the headers still showed the
mixed/multipart, so that's why I think it was stripped out of the mail).
Don't know if it makes any difference though :)
Mvgr,
Martin
On Mon, 2003-02-03 at 19:48, LOX wrote:
Seems like your attachment got stripped from the mail.
-1
Filtering can be done in most mail clients if the right subject prefixes
are used. A separate list is not necessary.
i.e. use [VOTE][Codec] and not just [VOTE]
for votes interesting for all projects you could use [VOTE][COMMONS] or
[VOTE][ALL] or similar
The cvsreader afaik is also used in turbine..
Probably fits into io a bit (assuming it's build on that).
When I think of codec cvs stuff doesn't really go through my mind to be
honest..
Mvgr,
martin
On Mon, 2003-02-03 at 20:45, Henri Yandell wrote:
I've a CSVReader, CSVWriter, and POI
just to check. csv not cvs :)
On 3 Feb 2003, Martin van den Bemt wrote:
The cvsreader afaik is also used in turbine..
Probably fits into io a bit (assuming it's build on that).
When I think of codec cvs stuff doesn't really go through my mind to be
honest..
Mvgr,
martin
On Mon,
Hello Allm
About:
org.apache.commons.lang.functor.*
Functor interfaces, grown from initial versions in Collections and
Patterns.
Does the introduction of this new package mean that Commons Collection will
depend on Commons Lang, if not, why not? It would seem to me that creating
such a
I just type cvs too often to get CSV typed correctly :)
I meant CSV :)
btw I like to see them in commons, but it will end up more for
db.apache.org if it is left up to me :) (written a simple db system
around csv a long while ago..)
Mvgr,
Martin
On Mon, 2003-02-03 at 21:04, Henri Yandell wrote:
On Mon, 3 Feb 2003, Gary Gregory wrote:
Hello Allm
About:
org.apache.commons.lang.functor.*
Functor interfaces, grown from initial versions in Collections and
Patterns.
Does the introduction of this new package mean that Commons Collection will
depend on Commons Lang, if not, why
here we go again...
Index: ConstructorUtils.java
===
RCS file:
/home/cvspublic/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/ConstructorUtils.java,v
retrieving revision 1.2
diff -u -r1.2 ConstructorUtils.java
---
mvdb2003/02/03 12:50:49
Modified:beanutils/src/java/org/apache/commons/beanutils
ConstructorUtils.java
Log:
Applying patch supplied by dimiter at blue-edge dot bg
In case you're interested here is a patch containing JavaDoc for the
ConstructorUtils
Applied thanx !
Mvgr,
Martin
On Mon, 2003-02-03 at 20:58, LOX wrote:
here we go again...
Index: ConstructorUtils.java
===
RCS file:
The Jakarta Commons Team is pleased to announce the 1.4 release of
Digester from the Apache Software Foundation. Digester is an XML-to-object
mapper used for (amongst other things) parsing XML configuration files.
This release contains several bug fixes together with enhanced support for
XML
Hi,
If anyone wants to add anything to commons-sql then do so now. I'm going
to copy the repo over to db.apache.org and rename the one in the
jakarta-commons.
Also, if the committers of dbutils and dbcp are interested in moving
their stuff over to db.apache.org I will help with that also.
--
hey martin!
since you're now a member of the beanutils team, you need to add your name
to the status file :)
- robert
On Monday, February 3, 2003, at 08:50 PM, [EMAIL PROTECTED] wrote:
mvdb2003/02/03 12:50:49
Modified:beanutils/src/java/org/apache/commons/beanutils
I don't consider myself a developer of beanutils when I apply a patch
from someone else ;)
But hey, rules are rules :)
Mvgr,
Martin
On Mon, 2003-02-03 at 22:02, robert burrell donkin wrote:
hey martin!
since you're now a member of the beanutils team, you need to add your name
to the status
rdonkin 2003/02/03 13:03:19
Modified:digester build.xml
Log:
Updated to new version number after 1.4 release
Revision ChangesPath
1.35 +2 -2 jakarta-commons/digester/build.xml
Index: build.xml
olegk 2003/02/03 13:21:20
Modified:httpclient/src/java/org/apache/commons/httpclient
HttpConstants.java
httpclient/src/java/org/apache/commons/httpclient/methods
PostMethod.java
costin 2003/02/03 13:42:32
Modified:modeler/src/java/org/apache/commons/modeler
AttributeInfo.java
Log:
Some implementation of JMX require it to be false (it is used for base mbean, not
for
model mbeans )
Revision ChangesPath
1.5 +5 -5
Here's some analysis:
These four classes are what I'm working from right now. Base64.java in
[codec] started out in HttpClient. XML-RPC also took the same Base64 source
and it looks like XML-RPC has given Base64 the most attention over the last
few months, fixing bugs, etc.
I propose that
I think I'd like to see dbcp follow dbutils, since we're in the processing
of refactoring some of the dbcp code out to dbutils. I don't know if
anyone else has an opinion on this however.
On Mon, 3 Feb 2003, Jason van Zyl wrote:
Hi,
If anyone wants to add anything to commons-sql then do so
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=16525.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
For us uninitiated, could someone give a short dissertation on what is
db.apache.org and why it would make sense to move these over? Not
objecting, but inquiring minds would like to know.
TIA
Steven Caswell
[EMAIL PROTECTED]
a.k.a Mungo Knotwise of Michel Delving
One ring to rule them all, one
luehe 2003/02/03 16:22:32
Log:
Import of EL source files
Status:
Vendor Tag: commons_el
Release Tags: r1-0
N jakarta-commons/el/project.properties
N jakarta-commons/el/LICENSE.txt
N jakarta-commons/el/PROPOSAL.html
N jakarta-commons/el/build.xml
N
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=16744.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
When I did a cvs import for jakarta-commons/el, I accidentally also imported
the jakarta-commons/el/dist and jakarta-commons/el/target dirs which were created
after executing ant dist.
I've tried to remove them from the repository, but keep getting this error message:
Access denied:
Has anyone looked at the bug #16581? I've attached a patch which merely
propagates the idle eviction properties to BasicDataSourceFactory.
--
Gerald TurnerEmail: [EMAIL PROTECTED]Phone: (503) 788-1720
GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5
On Mon, 3 Feb 2003, Jan Luehe wrote:
Date: Mon, 3 Feb 2003 18:55:03 -0800 (PST)
From: Jan Luehe [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED],
Jan Luehe [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [EL] Unable to remove
tobrien 2003/02/03 20:43:36
Modified:codec/src/java/org/apache/commons/codec Soundex.java
RefinedSoundex.java Metaphone.java
Log:
deprecated language codecs in codec package, well remove in 1 week
Revision ChangesPath
1.7 +3 -3
tobrien 2003/02/03 20:43:59
Modified:codec/src/java/org/apache/commons/codec/language
DoubleMetaphone.java Nysiis.java
Added: codec/src/java/org/apache/commons/codec/language
Metaphone.java RefinedSoundex.java Soundex.java
Log:
tobrien 2003/02/03 20:46:01
Modified:codec/src/test/org/apache/commons/codec TestAll.java
Added: codec/src/test/org/apache/commons/codec/language
TestMetaphone.java TestRefinedSoundex.java
TestSoundex.java
Removed:
tobrien 2003/02/03 20:46:29
Modified:codecbuild.xml
Log:
Removed dedicated base64 test target
Revision ChangesPath
1.7 +2 -2 jakarta-commons-sandbox/codec/build.xml
Index: build.xml
===
tobrien 2003/02/03 20:49:00
Modified:codecTODO
Log:
updated TODO list
Revision ChangesPath
1.5 +3 -2 jakarta-commons-sandbox/codec/TODO
Index: TODO
===
RCS file:
On Mon, 3 Feb 2003, Jan Luehe wrote:
Robert,
(4) Initial Committers
The initial committers will be identical to those of the Standard Taglib
project.
i'm unhappy with this since it implies that all current taglib committers
will be grandfathered in. a list of the people being
On Sun, 2 Feb 2003, robert burrell donkin wrote:
On Saturday, February 1, 2003, at 07:33 AM, Martin Cooper wrote:
On Wed, 29 Jan 2003, robert burrell donkin wrote:
we've had some requests from users who wanted to download a file upload
release. it'd be good to have a definite release
On Mon, 3 Feb 2003, robert burrell donkin wrote:
i've committed a basic maven based site for fileupload. shouldn't be too
hard to tweak it into shape (even for maven newbies ;)
Cool! Looks like the ball is in my court now... ;-)
--
Martin Cooper
- robert
On Mon, 3 Feb 2003, robert burrell donkin wrote:
the code for jexl is in the sandbox. now that jexl has been promoted, this
code needs to be moved into the commons repository and the commons web
site updated.
unless anyone else jumps in, i'll volunteer to make the move.
I have moved
tobrien 2003/02/03 21:46:47
jakarta-commons-sandbox/codec/src/java/org/apache/commons/codec/binary - New
directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
tobrien 2003/02/03 21:48:30
jakarta-commons-sandbox/codec/src/test/org/apache/commons/codec/binary - New
directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
tobrien 2003/02/03 21:50:00
Modified:codecTODO
codec/src/java/org/apache/commons/codec/base64 Base64.java
codec/src/test/org/apache/commons/codec TestAll.java
Added: codec/src/java/org/apache/commons/codec/binary Base64.java
Is there such a thing as conceptual dyslexia? I think I have it.. I left
out a parameter...
Redo those signatures:
public static byte[] encode( byte[] binaryData ) throws EncoderException
public static byte[] encode( byte[] binaryData,
boolean addNewline,
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
My proposal is that we add a series of boolean flags, int
fields to the method signature to allow client projects to specify
different levels of RFC compliance.
Alternatively you could support an ErrorHandler interface, and delegate
to that
tobrien 2003/02/03 22:37:42
Added: codecRELEASE-PLAN
Log:
Added a release plan
Revision ChangesPath
1.1 jakarta-commons-sandbox/codec/RELEASE-PLAN
Index: RELEASE-PLAN
===
tobrien 2003/02/03 22:37:58
Modified:codecTODO
Log:
updated TODO
Revision ChangesPath
1.7 +1 -0 jakarta-commons-sandbox/codec/TODO
Index: TODO
===
RCS file:
I tried to read to the end of the thread so far before replying.
If the feeling is that the classes will see more use distributed
separately from HttpClient, I concur with Henri's assessment below.
In message [EMAIL PROTECTED], Hen
ri Yandell writes:
I'm +1 to commons-uri.
As Tim points out,
craigmcc2003/02/03 23:28:14
Modified:beanutils/src/java/org/apache/commons/beanutils
BeanUtils.java
beanutils/src/test/org/apache/commons/beanutils
BeanUtilsTestCase.java DynaBeanUtilsTestCase.java
Log:
Enhance
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=16525.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Is that fixed now?
I tested this issue with HttpClient 2.0 alpha2 and the result was the same
(wrong encoding)!
Thomas
-Ursprüngliche Nachricht-
Von: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]]
Gesendet: Mittwoch, 15. Januar 2003 10:22
An: Commons HttpClient Project
Betreff: RE: POST
There is one further alternative to Jeffrey's suggestion. You can call
executeMethod, then get the response stream, then call close() on
that. The close on the response stream will trigger the right
sequence of events.
-Eric.
Simon Roberts wrote:
I guess the problem is really mine. I was
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=15654.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Michael Becke wrote:
[snip]
I've been looking into this a little more and I'm actually not sure if
AutoCloseInputStream should close the stream or not. I vaguely
remember when this was first written and the various interactions are
quite complex. In most cases the AutoCloseInputStream is
1 - 100 of 131 matches
Mail list logo
