Patch update, I have split the very long testRetrieve in
TestBaseConfiguration into smaller testGetBoolean, testGetLong...
methods. I have also reinforced the test on Configuration.getList.
Emmanuel Bourg
Emmanuel Bourg wrote:
Hi, here is a patch removing useless constructors, suite() and
Almost nobody knows what is custom, what scripts need rewriting, how
much work it will take, etc and probably a lack of interest in upgrading
bugzilla at all. But yeah, cannot speak for others...
Mvgr,
Martin
On Tue, 2004-01-13 at 11:15, Emmanuel Bourg wrote:
What was the issue preventing the
Janek Bogucki wrote:
#2
On
http://jakarta.apache.org/~scolebourne/collections3/license.html
the 'StatCvs Report' link is broken. It links to
http://jakarta.apache.org/~scolebourne/collections3/statcvs/index.html
How does the group feel about axing StatCVS reports from Jakarta Commons
Emmanuel,
Thanks for all of your help with release management for various commons
components, and taking the time to make sure that various sites are
maintained and updated. And now you've stepped up to the plate to
volunteer to upgrade our Bugzilla installation. If you are a committer,
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=26092.
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=26092.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Tim O'Brien wrote:
How does the group feel about axing StatCVS reports from Jakarta Commons
entirely. They are a rendering nightmare (takes too long), and they
encourage metric gather that is not entirely helpful. Does it really
matter that psteitz is a 7% committer, and that scole... is a
yoavs 2004/01/13 06:29:58
Modified:.build.xml
docs beanutils.html charter.html collections.html
commons.html components.html contributors.html
dbcp.html directory.html discovery.html el.html
yoavs 2004/01/13 07:02:06
Modified:daemon project.xml
daemon/xdocs index.xml
Log:
Corrected typos and release number.
Revision ChangesPath
1.7 +1 -1 jakarta-commons/daemon/project.xml
Index: project.xml
yoavs 2004/01/13 07:07:07
Modified:daemon RELEASE-NOTES.txt build.xml
Log:
Updated version references to 1.0 from 1.0-dev or 1.0-Alpha
Revision ChangesPath
1.2 +2 -2 jakarta-commons/daemon/RELEASE-NOTES.txt
Index: RELEASE-NOTES.txt
Thank you Tim, but I'm not a committer unfortunately. I'll contact Pier
and offer my help but I don't expect to gain his trust easily.
Emmanuel Bourg
Tim O'Brien wrote:
Emmanuel,
Thanks for all of your help with release management for various commons
components, and taking the time to make
I've filed 2 requests in Bugzilla :
Bug 26098 - Upgrade to Bugzilla 2.16.x
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26098
Bug 26099 - Promote Jakarta Commons components to Bugzilla products
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26099
Emmanuel
Tim O'Brien wrote:
Emmanuel,
On Jan 12, 2004, at 10:28 AM, Geir Magnusson Jr wrote:
2) A different approach, where the context is simple (allowing
recycling w/o much effort of other backing impls) and Jexl is smart
Regarding #2, I can see 2 approaches.
One is to do it during evaluate(), like you proposed, which will
I've been playing a bit with the Struts MessageResources lately, I'm
trying to use a Configuration as the underlying structure for storing
internationalized messages. This brings 2 interesting improvements,
interpolation and automatic reloading when it's committed.
However I stumbled on a
Hi Pete,
On Tue, 2004-01-13 at 16:41, peter royal wrote:
lets leverage the map! the map knows if a variable exists. So how about
JexlExpression.setExplicitVariableDeclaration( true ); and then Jexl
just does (in ASTIdentifier, and I think that might be the only
place..)
That would work.
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=26102.
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=26102.
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=26102.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Emmanuel Bourg wrote:
JIRA just like Bugzilla doesn't support per component version numbers
Agreed. Jira and newer versions of bugzilla are similar in that sense,
although Jira's user-customizable dashboard seems to make better use of it.
Jira also has far more powerful permission schemes.
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=25661.
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=24822.
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=24822.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
In Httpclient there is a Static class primarily for the use of
converting byte[]'s to ASCII strings and for returning a default
encoding when the reqeuested encoding is not supported.
Here is an example of the file:
Noel J. Bergman wrote:
Agreed. Jira and newer versions of bugzilla are similar in that sense,
although Jira's user-customizable dashboard seems to make better use of it.
Jira also has far more powerful permission schemes. The permission schemes
can be important. For example, it allows
I am -1 for moving Jakarta Commons as a --whole-- to JIRA,
If each sub-project of commons wants to move then thats ok.
Why: There has been a Buzilla 2.16.4 available for some time
that fixes several serious security issues. However, we haven't
upgraded to that version, or any of the other improved
Bill,
Your usage of Jexl is the first usage I know of which is separate from
Jelly. If you happen to have pointers, it would be nice to start a page
powered-by.
Paul
Just thought I would jump in here and say that I too am using Jexl in a
persistence engine (to be open sourced and housed
Emmanuel Bourg wrote:
I will check the latest version but I was under the impression bugzilla
had a fine grained permission system. Private access is definitely
supported by bugzilla, it's needed for security related bugs in Mozilla.
I don't see those in our version. I do see bug groups,
Mark,
Coincidentally, we just ended up deprecating HttpConstants class, having
migrated all the relevant functions to a new class named EncodingUtil. I
can't help thinking that Codec may also be a good place for what is now
EncodingUtil in HttpClient.
Cheers,
Oleg
On Tue, 2004-01-13 at 18:10,
rdonkin 2004/01/13 11:40:43
Modified:digester .cvsignore
Log:
Added match for maven temp propeties file that is often left around after a
documentation build.
Revision ChangesPath
1.5 +1 -0 jakarta-commons/digester/.cvsignore
Index: .cvsignore
rdonkin 2004/01/13 12:23:26
Modified:digester/src/java/org/apache/commons/digester package.html
Log:
Added debugging tips concerning SAX error handling.
Revision ChangesPath
1.25 +41 -1
jakarta-commons/digester/src/java/org/apache/commons/digester/package.html
rdonkin 2004/01/13 12:24:03
Modified:digester/xdocs navigation.xml
Log:
Added link to Digester guide to site navigation.
Revision ChangesPath
1.5 +2 -1 jakarta-commons/digester/xdocs/navigation.xml
Index: navigation.xml
[EMAIL PROTECTED] wrote:
I am -1 for moving Jakarta Commons as a --whole-- to JIRA,
If each sub-project of commons wants to move then thats ok.
Just to rewind the tape, this is a proposal *asking* what people want to do,
and proposing how a move might work. In terms of decision making, an
On Tue, 2004-01-13 at 17:22, Bill Horsman wrote:
(Yet) another solution:
Get the JexlContext to track which variables it was asked for. Note
which ones were known and which were not known. Then you can ask
JexlContext for the list at the end.
I got so enthused by this idea that I decided
rdonkin 2004/01/13 13:45:44
Modified:betwixt/src/test/org/apache/commons/betwixt/xmlunit Tag:
REFACTORING-BRANCH_2004-01-13 rss-example.xml
Log:
Initial commit of the refactoring stuff. It has not been cleared up (in the way that
I would have liked) but I
rdonkin 2004/01/13 13:53:18
Added: betwixt/src/test/org/apache/commons/betwixt/io/read Tag:
REFACTORING-BRANCH_2004-01-13 TestReadContext.java
Log:
WARNING CODE ON THIS BRANCH IS EXPERIMENTAL AND LIABLE TO CHANGE! Initial commit of
the refactoring stuff.
rdonkin 2004/01/13 13:57:54
Added: betwixt/src/java/org/apache/commons/betwixt/io/read Tag:
REFACTORING-BRANCH_2004-01-13 BeanBindAction.java
Log:
WARNING CODE ON THIS BRANCH IS EXPERIMENTAL AND LIABLE TO CHANGE! Initial commit of
the refactoring stuff. It
rdonkin 2004/01/13 13:59:34
Added: betwixt/src/test/org/apache/commons/betwixt/io/read Tag:
REFACTORING-BRANCH_2004-01-13
SimpleStringCollective.java
Log:
WARNING CODE ON THIS BRANCH IS EXPERIMENTAL AND LIABLE TO CHANGE! Initial
roxspring2004/01/13 14:01:23
Modified:cli/src/java/org/apache/commons/cli2 OptionException.java
Option.java HelpLine.java PropertyOption.java
CommandLineParser.java Comparators.java
Command.java ArgumentImpl.java
rdonkin 2004/01/13 14:08:04
Added: betwixt/src/test/org/apache/commons/betwixt/io/read Tag:
REFACTORING-BRANCH_2004-01-13
TestMappingActions.java
Log:
WARNING CODE ON THIS BRANCH IS EXPERIMENTAL AND LIABLE TO CHANGE! Initial commit
rdonkin 2004/01/13 14:08:27
Added: betwixt/src/test/org/apache/commons/betwixt/io/read Tag:
REFACTORING-BRANCH_2004-01-13 Elements.java
Log:
WARNING CODE ON THIS BRANCH IS EXPERIMENTAL AND LIABLE TO CHANGE! Initial commit of
the refactoring stuff. It has
rdonkin 2004/01/13 14:09:05
Added: betwixt/src/test/org/apache/commons/betwixt/io/read Tag:
REFACTORING-BRANCH_2004-01-13 Elements.betwixt
Log:
WARNING CODE ON THIS BRANCH IS EXPERIMENTAL AND LIABLE TO CHANGE! Initial commit of
the refactoring stuff. It
hi folks,
noel bergman from the incubator mailing list gave me the hint, that my
project would fit to the commons project.
i wrote a versatile container for software components that could be
embedded in different frameworks. i am using this right now as a
container for web components (container
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=26115.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
tobrien 2004/01/13 18:57:37
jakarta-commons/daemon/xdocs/style - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
tobrien 2004/01/13 18:58:08
Added: daemon/xdocs/style project.css
Log:
Daemon's Maven site noe includes a project.css that makes the Banner have a white
background
Revision ChangesPath
1.1 jakarta-commons/daemon/xdocs/style/project.css
Index:
tobrien 2004/01/13 19:08:22
Added: betwixt/xdocs/style project.css
Log:
Betwixt's Maven site now includes a project.css that makes the Banner have a white
background
Revision ChangesPath
1.1 jakarta-commons/betwixt/xdocs/style/project.css
Index:
tobrien 2004/01/13 19:15:53
Modified:betwixt project.properties
Removed: betwixt checkstyle.properties
Log:
Upgraded this Maven project to use settings that are compatible with Maven RC1.0.
Revision ChangesPath
1.9 +2 -2
tobrien 2004/01/13 19:21:53
jakarta-commons/cli/xdocs/style - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
tobrien 2004/01/13 19:22:22
Added: cli/xdocs/style project.css
Log:
CLI no contains a project.css that overrides banner and set banner's background to
white.
Revision ChangesPath
1.1 jakarta-commons/cli/xdocs/style/project.css
Index: project.css
tobrien 2004/01/13 19:24:22
Modified:codec/xdocs/style project.css
Log:
Codec now contains a project.css that overrides banner and set banner's background
to white.
Revision ChangesPath
1.2 +5 -3 jakarta-commons/codec/xdocs/style/project.css
Index:
tobrien 2004/01/13 19:30:20
jakarta-commons/collections/xdocs/style - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
tobrien 2004/01/13 19:30:51
Added: collections/xdocs/style project.css
Log:
Collections now contains a project.css that overrides banner and set banner's
background to white.
Revision ChangesPath
1.1 jakarta-commons/collections/xdocs/style/project.css
Stephen, that CSS for the white banner background has been committed.
Maven 1.0 RC1 uses tigris.css and maven.css, xdoc/style/project.css,
simply overrides the banner colors.
I didn't publish the site, I'll leave that to you.
Cheers.
Tim
Stephen Colebourne wrote:
From: Janek Bogucki [EMAIL
tobrien 2004/01/13 19:46:09
jakarta-commons/configuration/xdocs/style - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
tobrien 2004/01/13 19:52:37
Added: configuration/xdocs/style project.css
Log:
Configuration now contains a project.css that overrides banner and set banner's
background to white.
Revision ChangesPath
1.1
tobrien 2004/01/13 20:07:43
jakarta-commons/digester/src/media - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
tobrien 2004/01/13 20:08:06
Added: digester/src/media logo.xcf
Log:
Added a white background logo for Digester which is consistent with other commons
logos
Revision ChangesPath
1.1 jakarta-commons/digester/src/media/logo.xcf
Binary file
tobrien 2004/01/13 20:09:11
jakarta-commons/digester/xdocs/style - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
tobrien 2004/01/13 20:09:33
Added: digester/xdocs/style project.css
Log:
Digester now has a project.css which sets the banner background to white
Revision ChangesPath
1.1 jakarta-commons/digester/xdocs/style/project.css
Index: project.css
tobrien 2004/01/13 20:09:57
Added: digester/xdocs/images logo.png
Log:
Added a logo for Digester
Revision ChangesPath
1.1 jakarta-commons/digester/xdocs/images/logo.png
Binary file
tobrien 2004/01/13 20:10:21
Modified:digester project.xml
digester/xdocs navigation.xml
Log:
Added a link to Jakarta Commons in the top nav
Revision ChangesPath
1.17 +10 -0 jakarta-commons/digester/project.xml
Index: project.xml
tobrien 2004/01/13 20:24:55
jakarta-commons/beanutils/src/media - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
tobrien 2004/01/13 20:24:55
jakarta-commons/beanutils/xdocs/images - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
tobrien 2004/01/13 20:24:55
jakarta-commons/beanutils/xdocs/style - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
tobrien 2004/01/13 20:25:44
Modified:beanutils project.xml
beanutils/xdocs navigation.xml
Added: beanutils/src/media logo.xcf
beanutils/xdocs/images logo.png
beanutils/xdocs/style project.css
Log:
BeanUtils style updated to
tobrien 2004/01/13 20:31:56
Modified:beanutils/xdocs navigation.xml
Log:
Added Jakarta Commons link to top nav
Revision ChangesPath
1.3 +5 -0 jakarta-commons/beanutils/xdocs/navigation.xml
Index: navigation.xml
tobrien 2004/01/13 20:42:49
jakarta-commons/fileupload/src/media - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
tobrien 2004/01/13 20:42:49
jakarta-commons/fileupload/xdocs/style - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
tobrien 2004/01/13 20:43:54
Modified:fileupload project.xml
fileupload/xdocs navigation.xml
Added: fileupload/src/media logo.xcf
fileupload/xdocs/images logo.png
fileupload/xdocs/style project.css
Log:
FileUpload banner has white
tobrien 2004/01/13 20:44:40
jakarta-commons/latka/src/xdocs/style - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
tobrien 2004/01/13 20:55:46
Added: latka/src/xdocs/style project.css
Log:
Banner background is now white
Revision ChangesPath
1.1 jakarta-commons/latka/src/xdocs/style/project.css
Index: project.css
I am interested in getting involved in the Commons-Math project. I have
been a Java developer for about three years, but I don't know much about
math. I took business calc in college about 10 years ago and haven't
done much since. I have wanted to learn some more about math and I
thought this
tobrien 2004/01/13 21:05:26
jakarta-commons/primitives/xdocs/style - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
tobrien 2004/01/13 21:05:26
jakarta-commons/primitives/xdocs/images - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
tobrien 2004/01/13 21:06:13
Modified:primitives project.xml
primitives/xdocs navigation.xml
Added: primitives/src/media logo.xcf
primitives/xdocs/images logo.png
primitives/xdocs/style project.css
Log:
Updated Primitives site,
On Mon, 12 Jan 2004, Noel J. Bergman wrote:
Guys,
There are separate requests on the table to move BETWIXT, CLI, CODEC, JEXL
and CONFIGURATION from Bugzilla to JIRA. JELLY is already there.
Are there any other Jakarta Commons projects that want to migrate? Are
there any that do NOT want
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=20089.
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=24869.
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=26070.
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.
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.
Stéphane,
You can monitor the following bug report in order to track the progress
of this feature implementation.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24504
Cheers,
Oleg
On Mon, 2004-01-12 at 19:45, Stéphane Houle wrote:
Thank you Oleg Mark for your help!!!
I'll write a
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=25431.
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=25431.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Folks,
Anything left to be done for 2.0rc3?
Oleg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks Oleg,
I temporary fixed my problem but simply create my own class based on
FilePart and I changed this method:
/**
* Write the disposition header to the output stream
* @param out
*The output stream
* @throws IOException
*If an IO problem occurs
*/
protected
The only thing we need to is some testing. Are we sure that
authentication and proxy support is working well in 2.0? I've done
some tests with Digest and Basic authentication. Has anyone been
testing with NTLM? Once that has been done we are good to go I think.
Mike
On Jan 13, 2004, at
Mike,
Plain (non-proxied) host NTLM authentication works fine. I have no access to
authenticating NTLM proxy and thus unable to test NTLM proxy authentication. Alfonso,
were you able to test your application against the latest 2.0 snapshot?
It is not easy to expect people to test against a
If plain NTLM is working, that's good enough for me. 2.0rc3 vote
forthcoming.
Mike
On Jan 13, 2004, at 10:40 AM, Kalnichevski, Oleg wrote:
Mike,
Plain (non-proxied) host NTLM authentication works fine. I have no
access to authenticating NTLM proxy and thus unable to test NTLM proxy
I propose that we mark the latest code in CVS HTTPCLIENT_2_0_BRANCH as
RC3 and proceed with a release. Please vote as follows:
--
Vote: HttpClient 2.0 RC3 release
[ ] +1 I am in favor of the release, and will help
+1
I propose that we mark the latest code in CVS HTTPCLIENT_2_0_BRANCH as
RC3 and proceed with a release. Please vote as follows:
---
---
Vote: HttpClient 2.0 RC3 release
[ ] +1 I am in favor of the release, and will help
+0
(i wish i would be able to support it ...)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
+1
-Original Message-
From: Michael Becke [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 13, 2004 17:29
To: Commons HttpClient Project
Subject: [VOTE] 2.0 RC3 Release
I propose that we mark the latest code in CVS HTTPCLIENT_2_0_BRANCH as
RC3 and proceed with a release. Please vote
+0. (The support I can give is just having it used on a lot of
machines and reporting bugs, which I won't fully count as support.)
Thanks,
Sam
On Tuesday, January 13, 2004, at 11:28 AM, Michael Becke wrote:
I propose that we mark the latest code in CVS HTTPCLIENT_2_0_BRANCH as
RC3 and
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=25431.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Yes, I've been following that discussion as well. I'm definitely
interested in making the switch to JIRA. Bugzilla has served us pretty
well, but I find it somewhat unwieldy at times.
Mike
On Jan 13, 2004, at 11:44 AM, Kalnichevski, Oleg wrote:
There's currently a rather animated discussion
Mark,
Ironically, I just responded to your message on the commons-dev mailing
list. I do think that EncodingUtil would fit quite well in codec
Cheers,
Oleg
On Tue, 2004-01-13 at 20:19, Mark R. Diggory wrote:
Hey Guys, I didn't realize you were already doing this,
Shall I apply? Any strong opinions to not migrate to JIRA?
Oleg
On Tue, 2004-01-13 at 20:01, Michael Becke wrote:
Yes, I've been following that discussion as well. I'm definitely
interested in making the switch to JIRA. Bugzilla has served us pretty
well, but I find it somewhat unwieldy
Lol, I was trying to catch up with you...
Some of the stuff now in encodingUtil is dependent on HttpClient
NameValuePair etc. and seems specifically for managing the
encoding/building of query strings.
The ASCII stuff is just dependent in that it throws HttpclientError's
I suspect the later
Another feature of interest is the ContentType class in contributions, I
suspect this should be more dependent on some general mimetype
resolution functionality possibly via JAF or some comparable standard
mimetype mapping library. This is something I'm researching as well for
codec or lang
1 - 100 of 104 matches
Mail list logo
