Re: [ANNOUNCE] Release of Commons HttpClient 2.0.2
Hi,
I have been using HttpClient version 2.0.1. But have some problems while uploading
multiple files. Please let me know
1. Can I upload multiple files using httpclient api from client to server (client and
server running on different systems).
2. I worked with sample code at
http://www.theserverside.com/articles/article.tss?l=HttpClient_FileUpload. Everything
works fine if I run the sample on the same systems but I cannot do the same by making
the client and server on different systems.
I used the following sample at the above url
Listing 9-6. HttpMultiPartFileUpload.java
package com.commonsbook.chap9;
import java.io.File;
import java.io.IOException;
import org.apache.commons.httpclient.HttpClient;
import org.apache.commons.httpclient.methods.MultipartPostMethod;
public class HttpMultiPartFileUpload {
private static String url =
http://localhost:8080/HttpServerSideApp/ProcessFileUpload.jsp;;
public static void main(String[] args) throws IOException {
HttpClient client = new HttpClient();
MultipartPostMethod mPost = new MultipartPostMethod(url);
client.setConnectionTimeout(8000);
// Send any XML file as the body of the POST request
File f1 = new File(students.xml);
File f2 = new File(academy.xml);
File f3 = new File(academyRules.xml);
System.out.println(File1 Length = + f1.length());
System.out.println(File2 Length = + f2.length());
System.out.println(File3 Length = + f3.length());
mPost.addParameter(f1.getName(), f1);
mPost.addParameter(f2.getName(), f2);
mPost.addParameter(f3.getName(), f3);
int statusCode1 = client.executeMethod(mPost);
System.out.println(statusLine + mPost.getStatusLine());
mPost.releaseConnection();
}
}
and for processing file upload i used the following JSP
%@ page contentType=text/html;charset=windows-1252%
%@ page import=org.apache.commons.fileupload.DiskFileUpload%
%@ page import=org.apache.commons.fileupload.FileItem%
%@ page import=java.util.List%
%@ page import=java.util.Iterator%
%@ page import=java.io.File%
html
head
meta http-equiv=Content-Type content=text/html; charset=windows-1252
titleProcess File Upload/title
/head
%
System.out.println(Content Type =+request.getContentType());
DiskFileUpload fu = new DiskFileUpload();
// If file size exceeds, a FileUploadException will be thrown
fu.setSizeMax(100);
List fileItems = fu.parseRequest(request);
Iterator itr = fileItems.iterator();
while(itr.hasNext()) {
FileItem fi = (FileItem)itr.next();
//Check if not form field so as to only handle the file inputs
//else condition handles the submit button input
if(!fi.isFormField()) {
System.out.println(\nNAME: +fi.getName());
System.out.println(SIZE: +fi.getSize());
//System.out.println(fi.getOutputStream().toString());
File fNew= new File(application.getRealPath(/), fi.getName());
System.out.println(fNew.getAbsolutePath());
fi.write(fNew);
}
else {
System.out.println(Field =+fi.getFieldName());
}
}
%
body
Upload Successful!!
/body
/html
3. But I could not do the same by making the server and client on different systems.
4. Pl. let me know for the same purpose is there any patch available with current
version released. i.e.2.0.2
5. Is there a way to build Multipart request without putting the Http File Item in the
form.
i.e. dynamically getting the file Items created programmatically at client side
and
passing the Multipart request to the server
thanks,
Srinivas.
Michael Becke [EMAIL PROTECTED] wrote:
The Jakarta Commons team is pleased to announce the release of
HttpClient 2.0.2. This release greatly improves the performance of
executing methods where the response contains little or no content.
Please visit the HttpClient 2.0 web site
for more information on
HttpClient and this release.
Thank you,
Commons HttpClient Development Team
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: [ANNOUNCE] Release of Commons HttpClient 2.0.2
http://jakarta.apache.org/commons/httpclient/3.0/index.html
But what I see the new is 3.0.
what is different is 2.0 and 3.0
On Sun, 10 Oct 2004 23:12:15 -0700 (PDT), Srinivas Velidanda
[EMAIL PROTECTED] wrote:
Hi,
I have been using HttpClient version 2.0.1. But have some problems while uploading
multiple files. Please let me know
1. Can I upload multiple files using httpclient api from client to server (client
and server running on different systems).
2. I worked with sample code at
http://www.theserverside.com/articles/article.tss?l=HttpClient_FileUpload.
Everything works fine if I run the sample on the same systems but I cannot do the
same by making the client and server on different systems.
I used the following sample at the above url
Listing 9-6. HttpMultiPartFileUpload.java
package com.commonsbook.chap9;
import java.io.File;
import java.io.IOException;
import org.apache.commons.httpclient.HttpClient;
import org.apache.commons.httpclient.methods.MultipartPostMethod;
public class HttpMultiPartFileUpload {
private static String url =
http://localhost:8080/HttpServerSideApp/ProcessFileUpload.jsp;;
public static void main(String[] args) throws IOException {
HttpClient client = new HttpClient();
MultipartPostMethod mPost = new MultipartPostMethod(url);
client.setConnectionTimeout(8000);
// Send any XML file as the body of the POST request
File f1 = new File(students.xml);
File f2 = new File(academy.xml);
File f3 = new File(academyRules.xml);
System.out.println(File1 Length = + f1.length());
System.out.println(File2 Length = + f2.length());
System.out.println(File3 Length = + f3.length());
mPost.addParameter(f1.getName(), f1);
mPost.addParameter(f2.getName(), f2);
mPost.addParameter(f3.getName(), f3);
int statusCode1 = client.executeMethod(mPost);
System.out.println(statusLine + mPost.getStatusLine());
mPost.releaseConnection();
}
}
and for processing file upload i used the following JSP
%@ page contentType=text/html;charset=windows-1252%
%@ page import=org.apache.commons.fileupload.DiskFileUpload%
%@ page import=org.apache.commons.fileupload.FileItem%
%@ page import=java.util.List%
%@ page import=java.util.Iterator%
%@ page import=java.io.File%
html
head
meta http-equiv=Content-Type content=text/html; charset=windows-1252
titleProcess File Upload/title
/head
%
System.out.println(Content Type =+request.getContentType());
DiskFileUpload fu = new DiskFileUpload();
// If file size exceeds, a FileUploadException will be thrown
fu.setSizeMax(100);
List fileItems = fu.parseRequest(request);
Iterator itr = fileItems.iterator();
while(itr.hasNext()) {
FileItem fi = (FileItem)itr.next();
//Check if not form field so as to only handle the file inputs
//else condition handles the submit button input
if(!fi.isFormField()) {
System.out.println(\nNAME: +fi.getName());
System.out.println(SIZE: +fi.getSize());
//System.out.println(fi.getOutputStream().toString());
File fNew= new File(application.getRealPath(/), fi.getName());
System.out.println(fNew.getAbsolutePath());
fi.write(fNew);
}
else {
System.out.println(Field =+fi.getFieldName());
}
}
%
body
Upload Successful!!
/body
/html
3. But I could not do the same by making the server and client on different systems.
4. Pl. let me know for the same purpose is there any patch available with current
version released. i.e.2.0.2
5. Is there a way to build Multipart request without putting the Http File Item in
the form.
i.e. dynamically getting the file Items created programmatically at client side
and
passing the Multipart request to the server
thanks,
Srinivas.
Michael Becke [EMAIL PROTECTED] wrote:
The Jakarta Commons team is pleased to announce the release of
HttpClient 2.0.2. This release greatly improves the performance of
executing methods where the response contains little or no content.
Please visit the HttpClient 2.0 web site
for more information on
HttpClient and this release.
Thank you,
Commons HttpClient Development Team
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
Javen Fang - www.matrix.org.cn
--
Just for fun - Just do it
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Re: Bugzilla
Oh, man. No thunder, just emotional devastation. It has been quite an ugly squabble and have made a few non-friends among the Infrastructure folks. Anyways, we need to make an announcement on the site in order to preempt (some of) the confusion among the users. Finally this issue is done with and we can move on with the migration process Evil Comrade Oleg On Mon, 2004-10-11 at 04:46, Adrian Sutton wrote: Hi all, Oleg has done a fantastic job in finally getting HttpClient converted from a component to a real project in bugzilla. There are a couple of things remaining that some help could be used on: 1. Check that everything looks right after the migration (the standard bugzilla installation on nagoya should now show the migrated version). 2. Decide if we now want to convert over to JIRA or stay with Bugzilla. Most of our issues with bugzilla should be solved now that we're a full project, however JIRA is much better supported than Bugzilla so we may want to move anyway. Let me know your thoughts and we'll unleash evil comrade Oleg on the infrastructure team again. :) Three big cheers to Oleg for following through on this. I don't mean to steal the thunder of the announcement but figured I'd keep the messages flowing during the night shift (aka: Australian day time). Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 3420 4584 0422236329 35 Prenzler St Upper Mount Gravatt 4122 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] Release of Commons HttpClient 2.0.2
Javen
HttpClient 2.0.x represents the stable branch whereas HttpClient 3.0 is
still in ALPHA development stage and may be subject to API change. We
are planning to freeze the 3.0 API quite soon and start working toward
the code freeze and a first stable release
For detailed information on new features in HttpClient 3.0 please refer
to:
http://jakarta.apache.org/commons/httpclient/3.0/news.html
Oleg
On Mon, 2004-10-11 at 08:18, Javen Fang wrote:
http://jakarta.apache.org/commons/httpclient/3.0/index.html
But what I see the new is 3.0.
what is different is 2.0 and 3.0
On Sun, 10 Oct 2004 23:12:15 -0700 (PDT), Srinivas Velidanda
[EMAIL PROTECTED] wrote:
Hi,
I have been using HttpClient version 2.0.1. But have some problems while uploading
multiple files. Please let me know
1. Can I upload multiple files using httpclient api from client to server (client
and server running on different systems).
2. I worked with sample code at
http://www.theserverside.com/articles/article.tss?l=HttpClient_FileUpload.
Everything works fine if I run the sample on the same systems but I cannot do the
same by making the client and server on different systems.
I used the following sample at the above url
Listing 9-6. HttpMultiPartFileUpload.java
package com.commonsbook.chap9;
import java.io.File;
import java.io.IOException;
import org.apache.commons.httpclient.HttpClient;
import org.apache.commons.httpclient.methods.MultipartPostMethod;
public class HttpMultiPartFileUpload {
private static String url =
http://localhost:8080/HttpServerSideApp/ProcessFileUpload.jsp;;
public static void main(String[] args) throws IOException {
HttpClient client = new HttpClient();
MultipartPostMethod mPost = new MultipartPostMethod(url);
client.setConnectionTimeout(8000);
// Send any XML file as the body of the POST request
File f1 = new File(students.xml);
File f2 = new File(academy.xml);
File f3 = new File(academyRules.xml);
System.out.println(File1 Length = + f1.length());
System.out.println(File2 Length = + f2.length());
System.out.println(File3 Length = + f3.length());
mPost.addParameter(f1.getName(), f1);
mPost.addParameter(f2.getName(), f2);
mPost.addParameter(f3.getName(), f3);
int statusCode1 = client.executeMethod(mPost);
System.out.println(statusLine + mPost.getStatusLine());
mPost.releaseConnection();
}
}
and for processing file upload i used the following JSP
%@ page contentType=text/html;charset=windows-1252%
%@ page import=org.apache.commons.fileupload.DiskFileUpload%
%@ page import=org.apache.commons.fileupload.FileItem%
%@ page import=java.util.List%
%@ page import=java.util.Iterator%
%@ page import=java.io.File%
html
head
meta http-equiv=Content-Type content=text/html; charset=windows-1252
titleProcess File Upload/title
/head
%
System.out.println(Content Type =+request.getContentType());
DiskFileUpload fu = new DiskFileUpload();
// If file size exceeds, a FileUploadException will be thrown
fu.setSizeMax(100);
List fileItems = fu.parseRequest(request);
Iterator itr = fileItems.iterator();
while(itr.hasNext()) {
FileItem fi = (FileItem)itr.next();
//Check if not form field so as to only handle the file inputs
//else condition handles the submit button input
if(!fi.isFormField()) {
System.out.println(\nNAME: +fi.getName());
System.out.println(SIZE: +fi.getSize());
//System.out.println(fi.getOutputStream().toString());
File fNew= new File(application.getRealPath(/), fi.getName());
System.out.println(fNew.getAbsolutePath());
fi.write(fNew);
}
else {
System.out.println(Field =+fi.getFieldName());
}
}
%
body
Upload Successful!!
/body
/html
3. But I could not do the same by making the server and client on different
systems.
4. Pl. let me know for the same purpose is there any patch available with current
version released. i.e.2.0.2
5. Is there a way to build Multipart request without putting the Http File Item in
the form.
i.e. dynamically getting the file Items created programmatically at client side
and
passing the Multipart request to the server
thanks,
Srinivas.
Michael Becke [EMAIL PROTECTED] wrote:
The Jakarta Commons team is pleased to announce the release of
HttpClient 2.0.2. This release greatly improves the performance of
executing methods where the response contains little or no content.
Please visit the HttpClient 2.0 web site
for more information on
HttpClient and this release.
Thank you,
Re: [ANNOUNCE] Release of Commons HttpClient 2.0.2
Hi Sudhakar, Why should a personal opinion of one guy hurt? We are all entitled to have our own opinion. As imperfect as HttpClient may be, it is still being used by numerous state of the art projects such as Spring framework, and to me that counts more than an opinion of one guy. 1. API is not stable This is basically correct. See point 2. 2. API is flaky This is basically correct. The API is far from being perfect. This said, in my opinion is still wy better than Java Net API. The reason why we can't keep the API stable is because early on (before any of the current committers joined the project) a few unfortunate design have been made. Now we are facing an unpleasant task of fixing them while supporting the existing user base. This is not an easy task 3. No proper documentation and easy to understand explanation Allow me to disagree. Some folks expressed opinion that HttpClient had better documentation than other projects. http://www.onjava.com/pub/a/onjava/2003/06/25/commons.html?page=last This is not to say that documentation could not be better, but we rarely have people complaining about the quality of support for HttpClient 4. No proper examples provided by team to understand API. Allow me to disagree. See for yourself http://jakarta.apache.org/commons/httpclient/tutorial.html http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/examples/?only_with_tag=HTTPCLIENT_2_0_BRANCH 4. Security problems may araise Whenever you venture out of your home you are at risk of being hit by a bus. Whenever you have your computer connected to a public network, security problems may arise. What specific security problems that expert was referring to? 5. Takes much memory when compared with Java Net API Try posting 200MB file with Java Net API and tell me about memory consumption. 6. My code becomes complicated, if I use HttpCLient Whenever you write code, it can get complicated unless you keep it simple 7. As name it says limited to Http Protocol. - Which is not suitable for multi protocol implementations. This is correct. We have no plans changing that. So I need some clarifications from Development team of HttpClient API. I hope I get the Positive response from the team regarding all matters what I have mentioned above. I hope that clarifies things a little Cheers Oleg *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpClient with Applet to upload files using MultipartPost is required....
Hi Srinivas, Sorry for the delay in getting back to you. There really is nothing different about using HttpClient in an applet compared to an application. I suggest you first get HttpClient working for you in a standalone application and then move it into an applet. If you have trouble getting HttpClient to work in an application please post the code you're using and if possible the debug log (see http://jakarta.apache.org/commons/httpclient/logging.html ). Regards, Adrian Sutton. On 08/10/2004, at 7:01 PM, Srinivas Velidanda wrote: Hi Adrian Sutton, thanks for the mail. I need some help regarding using Applet with HttpClient. I am able to make the signed applet get opened in the Internet Explorer, but I got stuck up 1. couldn't grant permissions to read a particular folder at client side. 2. Even If I do that I am not clear with pass the multipart request created in the applet to the servlet. I have been working with it since 1 week but couldn't find the right solution. As far as I know applet can communicate to the servlet using the URLConnection, URLEncoder but how can I make the MultiparPost request linked to the request from applet. Pl. suggest me a solution., thank you, Srinivas. Adrian Sutton [EMAIL PROTECTED] wrote: On 08/10/2004, at 5:21 PM, Srinivas Velidanda wrote: Hi, can I get the sample java code to make the signed applet with HttpClient. No unfortunately we develop a commercial product so I can't release the code. However, the usage of HttpClient is exactly the same in an applet as an application. You do however need to make sure the applet is signed and that you are using at least Java 1.3 (ie: you can't be using the Microsoft JVM that is the default in Windows IE). When you load the applet it should bring up a security dialog asking if you want to give the applet permission to run, click yes and you have full permissions. If you don't see that dialog then the applet isn't correctly signed. thanks, Srinivas. Regards, Adrian Sutton -- Intencha tomorrow's technology today Ph: 3420 4584 0422236329 35 Prenzler St Upper Mount Gravatt 4122 Australia QLD www.intencha.com ATTACHMENT part 2 application/pgp-signature x-mac-type=70674453; name=PGP.sig - Do you Yahoo!? Yahoo! Mail - You care about security. So do we. -- Intencha tomorrow's technology today Ph: 3420 4584 0422236329 35 Prenzler St Upper Mount Gravatt 4122 Australia QLD www.intencha.com PGP.sig Description: This is a digitally signed message part
[ANNOUNCE] HttpClient is now a separate project in [Bugzilla] issue tracking system
HttpClient project has taken a very important step toward becoming a full-fledged Jakarta level project. From today, HttpClient is a separate project in Apache Bugzilla issue tracking system. It is no longer a component of the Commons project. Please use the following details when filing bug reports for 2.0 and 3.0 branches of HttpClient: Product: HttpClient Component: Commons HttpClient Use the following URL for convenience: http://issues.apache.org/bugzilla/enter_bug.cgi?product=HttpClient All the existing issues, closed and open, are still available under their usual URLs. With HttpClient being a separate project in Bugzilla we will be able to define release versions and target milestones independently from Jakarta Commons Oleg *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] HttpClient is now a separate project in [Bugzilla] issue tracking system
Awesome! Nice work Oleg. Mike Oleg Kalnichevski wrote: HttpClient project has taken a very important step toward becoming a full-fledged Jakarta level project. From today, HttpClient is a separate project in Apache Bugzilla issue tracking system. It is no longer a component of the Commons project. Please use the following details when filing bug reports for 2.0 and 3.0 branches of HttpClient: Product: HttpClient Component: Commons HttpClient Use the following URL for convenience: http://issues.apache.org/bugzilla/enter_bug.cgi?product=HttpClient All the existing issues, closed and open, are still available under their usual URLs. With HttpClient being a separate project in Bugzilla we will be able to define release versions and target milestones independently from Jakarta Commons Oleg *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Bugzilla] vs [JIRA] revisited
Folks Due to the recent upgrade of HttpClient to a full project in Bugzilla JIRA no longer has a definitive edge over Bugzilla. Nonetheless, JIRA still a newer and more flexible system which can potentially make our life and that of our users simpler. http://nagoya.apache.org/jira/browse/INFRA-74 The only fundamental gripe with JIRA that some folks have is that it is not open-source. I do not think we should try to be holier than the Pope himself, since too many projects have already defected to JIRA Religious reasons aside, I also foresee technical difficulties too. Currently (at least with Bugzilla 2.14.2) there appears no way to make a project completely read-only. Submission of new reports can be disabled, but one can still modify the existing bug reports. There is a few options: (1) Ask folks to resubmit their comments in JIRA when important / ignore modifications made in Bugzilla when unimportant. (2) Tweak Bugzilla a little to prevent mutation of existing reports. Note, supposedly Apache Bugzilla is already a fork. So, the real trouble here is to convince the Infrastructure folks to apply a patch, and more importantly reapply it every time Bugzilla is upgraded. Now, the REAL REAL trouble is that it almost took a full scale nuclear conflict between the Evil Russian Empire (me) and the Freedom Alliance (the Infrastructure team) to implement what turned out to be a fairly minor change to get HttpClient promoted to a project status. From now on, I am deeply skeptical about everything that has to do with Bugzilla maintenance. Besides, I may not survive yet another squabble with Noel. (3) Wait until other Jakarta Commons project migrate first. Long may be the wait, though So, what's the popular opinion on that? Non-committers are highly encouraged to voice their opinion too Evil Comrade Oleg *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Bugzilla] vs [JIRA] revisited
Hi Oleg, could we synchronize the switch with the 4.0 implementation? In other words, continue with Bugzilla for 2.0 and 3.0, but once work gets started on 4.0, where the API changes and the package names probably change, then the bug tracking system changes as well? cheers, Roland
Re: [Bugzilla] vs [JIRA] revisited
Hi Roland I agree this makes sense. I am not sure, though, whether we can reasonably expect things to happen in one 'Big Bang': mailing lists, new CVS repository, web site, JIRA migration and so on. Most likely not. Besides, unless we start getting MASSIVELY more feedback on 3.0, I am not sure what else we can do but start hacking on 4.0 branch while 3.0 still goes through its natural development cycle: alpha - beta - rc - release. I sense the work on 4.0 may well commence as early as next month. Basically that will buy us some time, but not much. I certainly want to start the discussion on the 4.0 architecture (at least in broad strokes) very, very soon. This, again, makes the issue of issue tracking system highly important, as we better have a sane road map and reasonably well articulated strategy as soon as people start asking what the heck Jakarta HttpClient 4.0 is all about and how on earth we ended up with 3 API incompatible branches. Oleg On Mon, 2004-10-11 at 16:43, Roland Weber wrote: Hi Oleg, could we synchronize the switch with the 4.0 implementation? In other words, continue with Bugzilla for 2.0 and 3.0, but once work gets started on 4.0, where the API changes and the package names probably change, then the bug tracking system changes as well? cheers, Roland *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
HttpClient Powered
Hi there, Thank you for developing HttpClient. I'm using it in a freeware product called Sunrise, which converts websites and newsfeeds for offline reading on your handheld. http://home.planet.nl/~fridael/sunrise/tour/ Best regards, Laurens Fridael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Bugzilla] vs [JIRA] revisited
Between Bugzilla and JIRA, JIRA is my preference. -D On Mon, 11 Oct 2004 17:34:12 +0200, Oleg Kalnichevski [EMAIL PROTECTED] wrote: Hi Roland I agree this makes sense. I am not sure, though, whether we can reasonably expect things to happen in one 'Big Bang': mailing lists, new CVS repository, web site, JIRA migration and so on. Most likely not. Besides, unless we start getting MASSIVELY more feedback on 3.0, I am not sure what else we can do but start hacking on 4.0 branch while 3.0 still goes through its natural development cycle: alpha - beta - rc - release. I sense the work on 4.0 may well commence as early as next month. Basically that will buy us some time, but not much. I certainly want to start the discussion on the 4.0 architecture (at least in broad strokes) very, very soon. This, again, makes the issue of issue tracking system highly important, as we better have a sane road map and reasonably well articulated strategy as soon as people start asking what the heck Jakarta HttpClient 4.0 is all about and how on earth we ended up with 3 API incompatible branches. Oleg On Mon, 2004-10-11 at 16:43, Roland Weber wrote: Hi Oleg, could we synchronize the switch with the 4.0 implementation? In other words, continue with Bugzilla for 2.0 and 3.0, but once work gets started on 4.0, where the API changes and the package names probably change, then the bug tracking system changes as well? cheers, Roland *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Bugzilla] vs [JIRA] revisited
I agree this makes sense. I am not sure, though, whether we can reasonably expect things to happen in one 'Big Bang': mailing lists, new CVS repository, web site, JIRA migration and so on. Most likely not. Another question is if we want to switch to Subversion when we go to 4.0. It sounds like Jakarta is moving in that direction. Also, if we're going to switch repos and change our package name it would seem like a good time. I agree that it may be difficult to do all these things at once, but I think if we start doing things now it shouldn't be too painful. The next item to move is probably the mailing list. This has been on my TODO list for a while now. I'll email infrastructure tonight and get the ball rolling. Besides, unless we start getting MASSIVELY more feedback on 3.0, I am not sure what else we can do but start hacking on 4.0 branch while 3.0 still goes through its natural development cycle: alpha - beta - rc - release. I sense the work on 4.0 may well commence as early as next month. Basically that will buy us some time, but not much. I certainly want to start the discussion on the 4.0 architecture (at least in broad strokes) very, very soon. Next month seems pretty soon, but I guess you never know. My guess was that it wouldn't happen until January. We definitely want a pretty solid plan before we get started though. This, again, makes the issue of issue tracking system highly important, as we better have a sane road map and reasonably well articulated strategy as soon as people start asking what the heck Jakarta HttpClient 4.0 is all about and how on earth we ended up with 3 API incompatible branches. Yes, I'm not looking forward to 3 supported APIs at the same time. Hopefully 2.0 will be mostly frozen by the time 4.0 gets started. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Invalid response tests
Hello All, I've been starting to refactor some of the webapp test and have come upon a bit of a problem. I'm not terribly familiar with the SimpleHttpServer setup so perhaps there is simple solution that is eluding me. The problem is that sending invalid responses can be quite difficult. Specifically I'm trying to send a response with content but no content length. Is there an easy way to do this? Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
