oglueck 2003/02/13 01:14:43
Modified:httpclient/src/examples ClientApp.java CookieDemoApp.java
CustomHttpConnection.java
MultipartFileUploadApp.java PostXML.java
TrivialApp.java
Log:
fixed tabbing (no tabs)
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-02-13/commons-jelly-tags-html.html
Buildfile: build.xml
init:
[mkdir] Created dir:
rwaldhoff2003/02/13 04:12:51
Modified:jux/src/test/org/apache/commons/jux
TestStringObjectTestCase.java
Log:
add a simple diagnostic test to probe the gump failure
Revision ChangesPath
1.2 +53 -2
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.
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=17044.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I would like to move the following packages to db.apache.org
o commons-sql
o commons-dbcp
o commons-dbutils
should we move them to db-commons or should they become db subprojects??
we can use irc.werken.com#db to discuss
martin
Why do we need to move commons-dbcp ?
Is it new, more active community for commons-dbcp in db.apache.org ?
- Original Message -
From: Martin Poeschl [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, February 13, 2003 6:02 PM
Subject: [vote] moving commons-sql, commons-dbcp and
mturk 2003/02/13 09:44:20
Modified:daemon/src/native/nt/procrun/bin procrun.dll procrun.exe
procrunw.exe
Log:
New binary versions
Revision ChangesPath
1.2 +12 -11
jakarta-commons-sandbox/daemon/src/native/nt/procrun/bin/procrun.dll
mturk 2003/02/13 09:45:30
Added: daemon/src/native/nt/procrun procgui.c
Log:
The WIN GUI system try and console interface.
Revision ChangesPath
1.1 jakarta-commons-sandbox/daemon/src/native/nt/procrun/procgui.c
Index: procgui.c
as the name indicates db.apache.org is for db related projects.
the db project is new but people will look for db related stuff there
and not at jakarta-commons .. so it makes sense to move the projects to
db.apache.com
martin
Juozas Baliuka wrote:
Why do we need to move commons-dbcp ?
Is it
mturk 2003/02/13 09:48:35
Modified:daemon/src/native/nt/procrun procrun.c procrun.dev procrun.h
procrun.rc procrun.vcproj procrund.dev procrunw.dev
readme.txt
Log:
Added GUI mode for PROCRUN_WINAPP mode.
This enables that
Hello,
I was looking into using the httpclient in an
application that requires client certificate
authentication. According to the JSSE documentation,
the mechanism for doing this is to get your
SSLSocketFactory from an SSLContext, which allows you
to specify the KeyManager and TrustManager. I
i'm not a committer for any of these components but if they are going to
be moved, i'd much prefer them to be moved into db-commons rather than
making them db subprojects.
BTW if someone over in db-land wants to create a website, i'll gladly
create a link from the jakarta commons nav bar.
-
There was some talk on taglibs-user about EL empty only working with
java.util.Map and java.util.List.
here's a (simple) patch for jexl that makes ASTEmptyOperator work for all
Collections.
Tim O'Brien
Index: src/java/org/apache/commons/jexl/parser/ASTEmptyFunction.java
rdonkin 2003/02/13 10:41:49
Modified:betwixt/src/java/org/apache/commons/betwixt XMLUtils.java
betwixt/src/java/org/apache/commons/betwixt/digester
XMLIntrospectorHelper.java
betwixt/src/java/org/apache/commons/betwixt/io
I took a pass at the current CVS code and I't seems to
be clean of any unwanted references.
I'd also like to take this opportunity to cast a
nobinding vote:
+1
in favor of a 1.0.0 release.
Winston Ojeda
--- Daniel F. Savarese [EMAIL PROTECTED] wrote:
Sounds good to me. My bias is toward
rdonkin 2003/02/13 11:24:21
Modified:betwixt/src/java/org/apache/commons/betwixt/io
SAXBeanWriter.java
betwixt/src/test/org/apache/commons/betwixt/io
TestSAXBeanWriter.java
betwixt/xdocs index.xml
Log:
hi Jakob
in future, could you please prefix posts about betwixt with [betwixt] and
could you make sure that you use a -u diff (see http://jakarta.apache.org/
commons/patches.html). thanks.
i've applied your second patch in a modified form - i've added a property
(rather than a constructor).
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=7135.
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=7226.
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=7226.
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=14848.
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=7226.
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=16038.
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.
I think link can be added from db.apache.org to commons-dbcp, I do not
think it is good idea to move dbcp at this time, but I see no problems for
sandbox components, It can make them more public.
as the name indicates db.apache.org is for db related projects.
the db project is new but people
two new bugs have been posted in bugzilla since i posted the release plan.
bug #17002 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17002 - i'm
not sure what to about this. opinion seems to be divided about whether
this should be changed or not. i'm unsure. craig - could you take a look
at
There appears to be (at least two) locations for releases that need to
be manually updated: one on jakarta.apache.org and one on
www.apache.org. Are we supposted to keep both of these manually
updated? Why are there two? I have an account on deadalus, but where
would I even go to modify
Martin Poeschl wrote:
as the name indicates db.apache.org is for db related projects.
the db project is new but people will look for db related stuff there
and not at jakarta-commons .. so it makes sense to move the projects to
db.apache.com
And people who are already use it will look for
Eric Johnson wrote:
Hello,
I was looking into using the httpclient in an
application that requires client certificate
authentication. According to the JSSE documentation,
the mechanism for doing this is to get your
SSLSocketFactory from an SSLContext, which allows you
to specify the
Just to put it out there, I also notice a number of commons subprojects
(jelly for one) are using http://www.ibiblio.org/maven/ for
distribution. Maybe its not a stretch to dream of the day that a
www.javafind.net/www.jarfind.net (i.e. www.rpmfind.net) service exists ;-)
-Mark Diggory
just to clear this up, jelly isn't using ibiblio to distribute an official
apache release. jelly is available from ibiblio but the official
distribution of apache software will always be done from the apache web
site.
- robert
On Thursday, February 13, 2003, at 08:30 PM, Mark R. Diggory
** this is just a resend, since I got no response, perhaps adding
the project in the subject will help .. **
hi all,
I am using SAXBeanWriter in a Cocoon Environment.
for this I had to patch the SAXBeanWriter to do the following:
I)
startElement( , qname, qname , atts ) instead of
Costin Manolache wrote:
Martin Poeschl wrote:
as the name indicates db.apache.org is for db related projects.
the db project is new but people will look for db related stuff there
and not at jakarta-commons .. so it makes sense to move the projects to
db.apache.com
And people who are
On Thu, 13 Feb 2003, Robert Leland wrote:
Costin Manolache wrote:
Martin Poeschl wrote:
as the name indicates db.apache.org is for db related projects.
the db project is new but people will look for db related stuff there
and not at jakarta-commons .. so it makes sense to move the
On Thu, 2003-02-13 at 11:02, Martin Poeschl wrote:
I would like to move the following packages to db.apache.org
o commons-sql
o commons-dbcp
o commons-dbutils
+1
should we move them to db-commons or should they become db subprojects??
we can use irc.werken.com#db to discuss
martin
Thanks for clearing that up :-)
robert burrell donkin wrote:
just to clear this up, jelly isn't using ibiblio to distribute an
official apache release. jelly is available from ibiblio but the
official distribution of apache software will always be done from the
apache web site.
- robert
On
olegk 2003/02/13 13:31:53
Modified:httpclient/src/java/org/apache/commons/httpclient
ChunkedInputStream.java HttpConnection.java
httpclient/src/java/org/apache/commons/httpclient/methods
EntityEnclosingMethod.java
Robert Leland wrote:
Costin Manolache wrote:
Martin Poeschl wrote:
as the name indicates db.apache.org is for db related projects.
the db project is new but people will look for db related stuff there
and not at jakarta-commons .. so it makes sense to move the projects to
db.apache.com
Costin Manolache wrote:
Robert Leland wrote:
Costin Manolache wrote:
Martin Poeschl wrote:
as the name indicates db.apache.org is for db related projects.
the db project is new but people will look for db related stuff there
and not at jakarta-commons .. so it makes sense to move the
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=17066.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hmmm, so even though www.apache.org and jakarta.apache.org are served
from the same physical machines, we are to keep two binary and source
repositories up to date with new releases? Why isn't one just a softlink
of the other?
And speaking of releases, why in commons do we have two packages
hi jacob
i think my reply and your reposted crossed in transit. if you missed it (i
changed the subject) it's in the archives:
http://marc.theaimsgroup.com/?l=jakarta-commons-devm=104516486803306w=2
- robert
On Thursday, February 13, 2003, at 07:34 PM, Jakob Praher wrote:
** this is just a
Fabulous :)
thx
On Thursday, February 13, 2003, at 01:21 PM, O'brien, Tim wrote:
There was some talk on taglibs-user about EL empty only working with
java.util.Map and java.util.List.
here's a (simple) patch for jexl that makes ASTEmptyOperator work for
all
Collections.
Tim
On Thu, 13 Feb 2003, Jeffrey Dever wrote:
Hmmm, so even though www.apache.org and jakarta.apache.org are served
from the same physical machines, we are to keep two binary and source
repositories up to date with new releases? Why isn't one just a softlink
of the other?
+1. I've not done a
Henri Yandell wrote:
On Thu, 13 Feb 2003, Jeffrey Dever wrote:
And speaking of releases, why in commons do we have two packages for
each release, one for source and one for binaries? These are small
components where the biggest thing about them is the generated javadoc
which is in both. I
On Thu, 13 Feb 2003, Mark R. Diggory wrote:
Henri Yandell wrote:
Is there any need to support both tar.gz and .zip? With the exception of
some minor pain on Apple machines for tar.gz [although I've never had this
myself], it seems we could ditch one of these distribution mechanisms.
A version of Apple's tar had some kind of bug. I'm not sure if that's
still there. The main problem with OS X is that the default [and only
reasonable] filing system is case insensitive [windows has this problem
though], and more painfully, the default unzipper stuffit likes to chop
filenames off
Daniel Walsh wrote:
I was under the impression, though, that the implementation that you spoke
of would require an HTML form, or some other type of UI - which my
application does not use. Is that not true?
No of course not. HttpClient provides all you need to tailor an
appropriate POST
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.
Daniel,
While others have provide you with alternative suggestions to pursue, I
had one additional thought. If all you are interested in sending is the
file name, you should be able to extract that from the HTTP PUT request
itself - unless of course you want the file name to put to be
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.
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.
Hi James,
I am known as Cookie Taliban here for imposing strict, at times literal,
interpretation of cookie related RFCs ;-)
First off all, RFC 2965 has not been implemented yet, even though
HttpClient offers limited support for set-cookie2 headers.
Currently HttpClient per default uses RFC2109
Good argument. I'd say you are right that cookies should be
accepted/rejected based on individual merits and not on the entire
cookie header. A patch (in unidiff format) would be helpful in
evaluation what you propose to change.
Jandalf.
Couball, James wrote:
Hello All,
I have a problem
~8-\
I have not been smoking, have I?
Thanks, Mike. You are absolutely right
How about this?
Cheers
Oleg
On Thu, 2003-02-13 at 23:57, Michael Becke wrote:
Looks like a good start. Maybe we can agree on it in little pieces:)
I noticed the following and am not sure if it is correct:
+
56 matches
Mail list logo
