[Q] How to merge 2 web.xml files?
Hi, I would like to merge 2 web.xml files programmatically and generate a new web.xml. Do you know if there's some library or code that already does this? I know Tomcat has a global web.xml. Is there some code I could use from Tomcat? Does anyone has a DVSL/XSL/other stylesheet for making this transformation? Thanks a lot -Vincent -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
how many committers?
Hi, Can someone tell me how many committers there are on: - Tomcat 3.x - Tomcat 4.x - Tomcat 5.x Thanks -Vincent Note: I have not found a way to access the CVS avail file in /home/cvs (it seems I don't have the rights). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Proposal] Tomcat and Cactus (Repost)
Thanks to speak your mind Costin. At least you answered. I would have liked more feedback from other committers. For the time being I'll prepare a cactification script for Tomcat that will be delivered with Cactus. BTW, is there any problem if we create in cactusland a specially packaged Tomcat version that is cactus-aware ? I'm not sure yet we want to follow that route but if we wanted to do this and put it in the cactus release directory, would you see any problem ? I'll repost in 6 months ... :-) Thanks -Vincent Sidenote: I believe Cactus could very effectively be used as a regression testing tool for the Tomcat project. It has already discovered problems in the past. I haven't looked at the Watchdog project but it could be either a replacement or a complement to it. You should try it at some point. I would love to hear comments of what you don't like/do like. Quick start up guide for Tomcat is available here : http://jakarta.apache.org/cactus/1.4/howto_tomcat.html (needs only 10 minutes). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 24 May 2002 19:41 To: Tomcat Users List Cc: List Tomcat-Dev Subject: Re: [Proposal] Tomcat and Cactus (Repost) On Fri, 24 May 2002, Vincent Massol wrote: I'm reposting in the secret hope that I got no response to this email I sent last week because no one saw it in the flood of Tomcat emails ! If I get no answer this time, I will understand that no one finds this of interest and will try again in 6 months - 1 year :-) I think it would be a good idea :-), there is already far too much going on, with all the new features and changes ( jmx, 4.1, jk2, jasper2, coyote, etc ). Costin Thanks -Vincent Hi Tomcat developers, This is a proposal to bring Jakarta Tomcat and Jakarta Cactus (http://jakarta.apache.org/cactus) closer. I hope you'll like it. (0) Rationale Jakarta Cactus is a unit testing framework for testing Servlet, Taglibs and Filters. Jakarta Tomcat is a Servlet engine (Servlet, Taglibs, Filters). They are both part of the Jakarta community. At the moment, there are no existing Servlet container that have an easy way to unit test Servlets. The idea is to bring this ease of use to Tomcat by making it easy to use Cactus within Tomcat (in other words, add a unit testing service to Tomcat). (1) Scope of the proposal a) To bundle Cactus within Tomcat so that it provides a unique ease of use for Tomcat users who wishes to test their servlet code b) To make Cactus the official Tomcat test framework for end users (1) From the point of view of Tomcat users By providing the bundling defined in point (2) below, Tomcat end users would only have to do the following to test their code (see http://jakarta.apache.org/cactus/1.4/howto_tomcat.html, steps 4 to 6) : a) Create Cactus test classes in their WEB-INF/classes directory b) Open a browser and type the URL of the Cactus test runner, passing the name of the test class (see the link above for details) (2) Cactus bundling in Tomcat Bundling Cactus in Tomcat means (see steps 1 to 3 on the above link) : a) Adding the following jars to common/lib : cactus.jar, junit.jar, httpclient.jar, aspectjrt.jar (total of 423 KB) b) Adding the Cactus servlet test runner and redirector servlet and mappings in conf/web.xml (3) Versions The target Tomcat version for this proposal is 4.0 and greater. The Cactus one is 1.4 and greater (note that Cactus 1.4 is not released yet and is still in CVS - It can be downloaded from the nightly build). Comments, ideas ? Thank you -Vincent (from the Cactus team) -- To unsubscribe, e-mail: mailto:tomcat-user- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-user- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Proposal] Tomcat and Cactus (Repost)
That defeats the purpose of that Tomcat integration. The idea is that the Cactus jars would be part of the common libraries of a Tomcat installation so that each web application does not have to include the cactus jars and setup in its own war ... The idea is to bring testing as a service provided by the container, not the other way around. -Vincent -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 25 May 2002 23:39 To: Tomcat Users List Cc: 'Tomcat Developers List' Subject: RE: [Proposal] Tomcat and Cactus (Repost) I would prefer to see a self-contained WAR file ( or a set of self-contained wars ). Costin On Sat, 25 May 2002, Vincent Massol wrote: Thanks to speak your mind Costin. At least you answered. I would have liked more feedback from other committers. For the time being I'll prepare a cactification script for Tomcat that will be delivered with Cactus. BTW, is there any problem if we create in cactusland a specially packaged Tomcat version that is cactus-aware ? I'm not sure yet we want to follow that route but if we wanted to do this and put it in the cactus release directory, would you see any problem ? I'll repost in 6 months ... :-) Thanks -Vincent Sidenote: I believe Cactus could very effectively be used as a regression testing tool for the Tomcat project. It has already discovered problems in the past. I haven't looked at the Watchdog project but it could be either a replacement or a complement to it. You should try it at some point. I would love to hear comments of what you don't like/do like. Quick start up guide for Tomcat is available here : http://jakarta.apache.org/cactus/1.4/howto_tomcat.html (needs only 10 minutes). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 24 May 2002 19:41 To: Tomcat Users List Cc: List Tomcat-Dev Subject: Re: [Proposal] Tomcat and Cactus (Repost) On Fri, 24 May 2002, Vincent Massol wrote: I'm reposting in the secret hope that I got no response to this email I sent last week because no one saw it in the flood of Tomcat emails ! If I get no answer this time, I will understand that no one finds this of interest and will try again in 6 months - 1 year :-) I think it would be a good idea :-), there is already far too much going on, with all the new features and changes ( jmx, 4.1, jk2, jasper2, coyote, etc ). Costin Thanks -Vincent Hi Tomcat developers, This is a proposal to bring Jakarta Tomcat and Jakarta Cactus (http://jakarta.apache.org/cactus) closer. I hope you'll like it. (0) Rationale Jakarta Cactus is a unit testing framework for testing Servlet, Taglibs and Filters. Jakarta Tomcat is a Servlet engine (Servlet, Taglibs, Filters). They are both part of the Jakarta community. At the moment, there are no existing Servlet container that have an easy way to unit test Servlets. The idea is to bring this ease of use to Tomcat by making it easy to use Cactus within Tomcat (in other words, add a unit testing service to Tomcat). (1) Scope of the proposal a) To bundle Cactus within Tomcat so that it provides a unique ease of use for Tomcat users who wishes to test their servlet code b) To make Cactus the official Tomcat test framework for end users (1) From the point of view of Tomcat users By providing the bundling defined in point (2) below, Tomcat end users would only have to do the following to test their code (see http://jakarta.apache.org/cactus/1.4/howto_tomcat.html, steps 4 to 6) : a) Create Cactus test classes in their WEB-INF/classes directory b) Open a browser and type the URL of the Cactus test runner, passing the name of the test class (see the link above for details) (2) Cactus bundling in Tomcat Bundling Cactus in Tomcat means (see steps 1 to 3 on the above link) : a) Adding the following jars to common/lib : cactus.jar, junit.jar, httpclient.jar, aspectjrt.jar (total of 423 KB) b) Adding the Cactus servlet test runner and redirector servlet and mappings in conf/web.xml (3) Versions The target Tomcat version for this proposal is 4.0 and greater. The Cactus one is 1.4 and greater (note that Cactus 1.4 is not released yet and is still in CVS - It can be downloaded from the nightly build). Comments, ideas ? Thank you -Vincent (from the Cactus team) -- To unsubscribe, e-mail: mailto:tomcat-user- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-user- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED
[Proposal] Tomcat and Cactus
Hi Tomcat developers, This is a proposal to bring Jakarta Tomcat and Jakarta Cactus (http://jakarta.apache.org/cactus) closer. I hope you'll like it. (0) Rationale Jakarta Cactus is a unit testing framework for testing Servlet, Taglibs and Filters. Jakarta Tomcat is a Servlet engine (Servlet, Taglibs, Filters). They are both part of the Jakarta community. At the moment, there are no existing Servlet container that have an easy way to unit test Servlets. The idea is to bring this ease of use to Tomcat by making it easy to use Cactus within Tomcat (in other words, add a unit testing service to Tomcat). (1) Scope of the proposal a) To bundle Cactus within Tomcat so that it provides a unique ease of use for Tomcat users who wishes to test their servlet code b) To make Cactus the official Tomcat test framework for end users (1) From the point of view of Tomcat users By providing the bundling defined in point (2) below, Tomcat end users would only have to do the following to test their code (see http://jakarta.apache.org/cactus/1.4/howto_tomcat.html, steps 4 to 6) : a) Create Cactus test classes in their WEB-INF/classes directory b) Open a browser and type the URL of the Cactus test runner, passing the name of the test class (see the link above for details) (2) Cactus bundling in Tomcat Bundling Cactus in Tomcat means (see steps 1 to 3 on the above link) : a) Adding the following jars to common/lib : cactus.jar, junit.jar, httpclient.jar, aspectjrt.jar (total of 423 KB) b) Adding the Cactus servlet test runner and redirector servlet and mappings in conf/web.xml (3) Versions The target Tomcat version for this proposal is 4.0 and greater. The Cactus one is 1.4 and greater (note that Cactus 1.4 is not released yet and is still in CVS - It can be downloaded from the nightly build). Comments, ideas ? Thank you -Vincent (from the Cactus team) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 - Cactus Issue
Ok. Thanks Costin. What I'll keep in mind is that it is complex ... ;-) -Vincent -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 08 February 2002 00:28 To: Tomcat Developers List Subject: RE: Tomcat 3.3 - Cactus Issue On Thu, 7 Feb 2002, Vincent Massol wrote: Last thing I'd like to confirm : When data is sent over a socket, it will fill the socket buffer (at the client side) and then sending of data will block until the server side reads from the socket buffer ? If The first part - I'm not sure. I expect the TCP stack to be able to send some chunks of data without buffering and some with buffering. The BSD book has some nice pictures :-) The client may block until the server reads - TCP has flow control, but again it's hard to predict when does it happen ( but more likely for very large chunks of data ). the server closes the socket and there is data in the socket buffer, on the client side, the client socket will report an exception. Is that correct ? The server can't know if there's data on the client's buffer. The whole thing is very complicated - I allways had doubts that I understand it, and explaining it corectly is beyond my ability. What I know for sure is that you _may_ get an exception ( on some OSes ) if there is data in the buffer of the side that is issuing the close(), so that's the first thing I check. If close() is 'clean', i.e. all data has been send/received - there's no exception. If an exception is generated, things are very intersting on some systems - it may be possible that you'll get it out-of-band, i.e. you'll be interrupted before reading the whole response, even if data was sent completely and received. That was another difficult bug, when the client saw only a partial response page - and was caused by the same problem, on OS where the ABORT is sent as soon as it is received ( which I think is the correct behavior ) and the read() will not continue to get available data. Costin -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 - Cactus Issue
Sorry guys for not jumping in earlier.
Here is some more information on how Cactus works and what it does.
Background info on the problem
--
The problem that I reported occurs when I run Cactus own suite of Test.
As you know Cactus is a testing framework. It happens that I use Cactus
tests to test Cactus itself (err ... ok so far ? :-)).
On the client side
--
* The HTTP connection is made using the HttpURLConnection class.
Depending on the test case, it is a GET request or a POST one (or both).
* The client side waits for a reponse from the server side (Tomcat) with
the following code :
private InputStream bufferInputStream(InputStream theInputStream)
throws IOException
{
ByteArrayOutputStream os =
new ByteArrayOutputStream(DEFAULT_CHUNK_SIZE);
copy(theInputStream, os);
ByteArrayInputStream bais =
new ByteArrayInputStream(os.toByteArray());
return bais;
}
private void copy(InputStream theInputStream, OutputStream
theOutputStream)
throws IOException
{
// Only copy if there are data to copy ... The problem is that not
// all servers return a content-length header. If there is no header
// getContentLength() returns -1. It seems to work and it seems
// that all servers that return no content-length header also do
// not block on read() operations !
if (this.delegate.getContentLength() != 0) {
byte[] buf = new byte[DEFAULT_CHUNK_SIZE];
int count;
while (-1 != (count = theInputStream.read(buf))) {
theOutputStream.write(buf, 0, count);
}
}
}
On the server side
--
Cactus has a servlet (called by the client side). The client side passes
information on what class and what method to call and the servlet calls
the method using reflection.
Misc ideas
--
There are several test cases that are called before the one that fails
(testPostMethod) :
[junit] Testcase: testLongProcess took 3.745 sec
[junit] Testcase: testLotsOfData took 0.071 sec
[junit] Testcase: testReadServletOutputStream took 0.05 sec
[junit] Testcase: testPostMethod took 0.03 sec
[junit] Caused an ERROR
[junit] Connection aborted by peer: JVM_recv in socket input stream read
[junit] java.net.SocketException: Connection aborted by peer: JVM_recv
in socket input stream read
The particularity of testPostMethod is that it sends information both in
the URL (as parameters) and in the request BODY in POST form.
Thus, there is some POST data sent !
Thanks for your help, both of you(thanks Costin to jump in !).
-Vincent
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 05 February 2002 19:46
To: Tomcat Developers List
Subject: RE: Tomcat 3.3 - Cactus Issue
On Tue, 5 Feb 2002, Larry Isaacs wrote:
I looked for this and didn't find that there was any POST data
sent and none was read. I certainly could have missed something.
I don't completely understand everything that Cactus' controller
servlet does on the Tomcat side. However, I think I checked to
see what is.available() was reporting, in TcpConnector, and
believe it was zero during Windows runs which never failed for me.
If extra unread characters are present, this shouldn't be
zero if the test succeeds. Or am I still missing something?
I'll try to check again.
On linux, you may be able to do a tcpdump and look for ABORTs,
that would be a good sign we're in this particular case.
An intersting note is that different impl. of TCP send or
not the ABORT - even for the same OS. I never understood
why ( it may even be settable somewhere ) - the spec seems
to require it.
One question - with the sleep(), do you do an isAvailable()/skip()
after the sleep ?
One easy thing to check is to do a Request.getContentLength() and
check Request.available ( it should be the length of the unread
body ).
I'll try to reproduce it and check this.
Costin
--
To unsubscribe, e-mail: mailto:tomcat-dev-
[EMAIL PROTECTED]
For additional commands, e-mail: mailto:tomcat-dev-
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 - Cactus Issue
Costin, See inline -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 05 February 2002 19:08 To: Tomcat Developers List Subject: Re: Tomcat 3.3 - Cactus Issue On Tue, 5 Feb 2002 [EMAIL PROTECTED] wrote: Most of the time it happens when something is still in the write buffer ( i.e. unsent or unread ), and the remote side is closing the connection. I'll try again: Assuming CLIENT sending data to SERVER. The exception happens when: - server has received some data from client ( so client believes the data reached the destionation ). The data is in some OS buffer. - server dies or close() the socket, without reading the data from the OS buffer - some OSes have a TCP implementation that does what I believe to be right - send an ABORT ( instead of the regular CLOSE ). - the client will receive the ABORT and throw the exception ( that coresponds to SIGPIPE if the same thing would be done locally ) ( it seems my original mail was not very clear ). My feeling is that we are exaclty in this case - the logic to close the socket is trying to read the remaining data from the available() buffer ( impl. of the fix for extra CRLF bug ), but the impl is likely to fail on a fast OS or on certain threading models where the CLIENT may send aditional data between we read the input buffer and close(). Vincent: is your test servlet reading the body i.e. calls getParameters() if it's a url-encoded body, or read the full stream ? I do not use getParameters() anywhere in the code because I want to be able to call getReader() or getInputStream(). Thus I have some utility code to extract parameter from the query string directly. -Vincent If not, I believe the current behavior is correct and shouldn't be changed - it signals the CLIENT that whatever it posted was not read, and that's a very usefull information we shouldn't hide. If this is not the case, and the servlet has read the body - than it's a serious problem. Costin -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 - Cactus Issue
-Original Message-
From: Larry Isaacs [mailto:[EMAIL PROTECTED]]
Sent: 07 February 2002 14:16
To: 'Tomcat Developers List'
Subject: RE: Tomcat 3.3 - Cactus Issue
For the testPostMethod test, can you point me to where in
Cactus, the POST data is added/generated and where in the
server side code it is read.
On the client side,
org.apache.cactus.client.HttpClientHelper.addParametersPost()
On the server side, the POST parameters are not read by Cactus itself
(Cactus is transparent in that regards). Cactus does pass some internal
parameters (like class name, method name, etc) but always in the URL.
These are read using the
org.apache.cactus.server.ServletUtil.getQueryStringParameter()
The test cases read parameters the way they want (usually using
request.getParameter()). However, the testPostMethod() test do not read
the POST parameter.
Does the latest 3.3.1-dev still fails on your laptop in
spite a recent change to dump unread charecters?
I've just tried with the nightly build from 6/02/2002 and it still fails
(I tried 3 times and it failed on the third try).
Thanks.
Larry
-Original Message-
From: Vincent Massol [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 07, 2002 8:09 AM
To: 'Tomcat Developers List'
Subject: RE: Tomcat 3.3 - Cactus Issue
Sorry guys for not jumping in earlier.
Here is some more information on how Cactus works and what it does.
Background info on the problem
--
The problem that I reported occurs when I run Cactus own
suite of Test.
As you know Cactus is a testing framework. It happens that I
use Cactus
tests to test Cactus itself (err ... ok so far ? :-)).
On the client side
--
* The HTTP connection is made using the HttpURLConnection class.
Depending on the test case, it is a GET request or a POST one
(or both).
* The client side waits for a reponse from the server side
(Tomcat) with
the following code :
private InputStream bufferInputStream(InputStream theInputStream)
throws IOException
{
ByteArrayOutputStream os =
new ByteArrayOutputStream(DEFAULT_CHUNK_SIZE);
copy(theInputStream, os);
ByteArrayInputStream bais =
new ByteArrayInputStream(os.toByteArray());
return bais;
}
private void copy(InputStream theInputStream, OutputStream
theOutputStream)
throws IOException
{
// Only copy if there are data to copy ... The problem is that
not
// all servers return a content-length header. If there
is no header
// getContentLength() returns -1. It seems to work and it seems
// that all servers that return no content-length header also do
// not block on read() operations !
if (this.delegate.getContentLength() != 0) {
byte[] buf = new byte[DEFAULT_CHUNK_SIZE];
int count;
while (-1 != (count = theInputStream.read(buf))) {
theOutputStream.write(buf, 0, count);
}
}
}
On the server side
--
Cactus has a servlet (called by the client side). The client
side passes
information on what class and what method to call and the
servlet calls
the method using reflection.
Misc ideas
--
There are several test cases that are called before the one that
fails
(testPostMethod) :
[junit] Testcase: testLongProcess took 3.745 sec
[junit] Testcase: testLotsOfData took 0.071 sec
[junit] Testcase: testReadServletOutputStream took 0.05 sec
[junit] Testcase: testPostMethod took 0.03 sec
[junit] Caused an ERROR
[junit] Connection aborted by peer: JVM_recv in socket input
stream read
[junit] java.net.SocketException: Connection aborted by peer:
JVM_recv
in socket input stream read
The particularity of testPostMethod is that it sends
information both in
the URL (as parameters) and in the request BODY in POST form.
Thus, there is some POST data sent !
Thanks for your help, both of you(thanks Costin to jump in !).
-Vincent
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 05 February 2002 19:46
To: Tomcat Developers List
Subject: RE: Tomcat 3.3 - Cactus Issue
On Tue, 5 Feb 2002, Larry Isaacs wrote:
I looked for this and didn't find that there was any POST data
sent and none was read. I certainly could have missed
something.
I don't completely understand everything that Cactus' controller
servlet does on the Tomcat side. However, I think I checked to
see what is.available() was reporting, in TcpConnector, and
believe it was zero during Windows runs which never failed for
me.
If extra unread characters are present, this shouldn't be
zero if the test succeeds. Or am I still missing something?
I'll try to check again.
On linux, you may be able to do a tcpdump and look for ABORTs,
that would
RE: Tomcat 3.3 - Cactus Issue
Larry,
WebRequest.addParameter(param, value, WebRequest.POST_METHOD) adds
(param, value) to a hashtable (retrieved by getParameterNamesPost() in
the code snippet below) that later (in HttpClientHelper.
addParametersPost()) will be used to add all the parameters as POST
data.
Here are the relevant bits in HttpClientHelper :
Line 135:
// Choose the method that we will use to post data :
// - If at least one parameter is to be sent in the request body,
then
// we are doing a POST.
// - If user data has been specified, then we are doing a POST
if (theRequest.getParameterNamesPost().hasMoreElements() ||
(theRequest.getUserData() != null)) {
connection.setDoOutput(true);
} else {
connection.setDoOutput(false);
}
Line 284: PrintWriter out = new
PrintWriter(getConnectionStream(theConnection));
Line 313: out.print(queryString.toString());
out.close();
-Vincent
-Original Message-
From: Larry Isaacs [mailto:[EMAIL PROTECTED]]
Sent: 07 February 2002 15:43
To: Tomcat Developers List
Subject: RE: Tomcat 3.3 - Cactus Issue
Thanks for the info. However, I never found where
testPostMethod was using any POST data in the request.
I only see:
public void beginPostMethod(WebRequest theRequest)
{
theRequest.addParameter(param, value,
WebRequest.POST_METHOD);
}
Is there some place I'm not looking where POST data is
added as part of the client handling for this test?
Cheers,
Larry
-Original Message-
From: Vincent Massol [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 07, 2002 10:15 AM
To: 'Tomcat Developers List'
Subject: RE: Tomcat 3.3 - Cactus Issue
-Original Message-
From: Larry Isaacs [mailto:[EMAIL PROTECTED]]
Sent: 07 February 2002 14:16
To: 'Tomcat Developers List'
Subject: RE: Tomcat 3.3 - Cactus Issue
For the testPostMethod test, can you point me to where in
Cactus, the POST data is added/generated and where in the
server side code it is read.
On the client side,
org.apache.cactus.client.HttpClientHelper.addParametersPost()
On the server side, the POST parameters are not read by Cactus
itself
(Cactus is transparent in that regards). Cactus does pass
some internal
parameters (like class name, method name, etc) but always in the
URL.
These are read using the
org.apache.cactus.server.ServletUtil.getQueryStringParameter()
The test cases read parameters the way they want (usually using
request.getParameter()). However, the testPostMethod() test
do not read
the POST parameter.
Does the latest 3.3.1-dev still fails on your laptop in
spite a recent change to dump unread charecters?
I've just tried with the nightly build from 6/02/2002 and it
still fails
(I tried 3 times and it failed on the third try).
Thanks.
Larry
--
To unsubscribe, e-mail: mailto:tomcat-dev-
[EMAIL PROTECTED]
For additional commands, e-mail: mailto:tomcat-dev-
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 - Cactus Issue
Hey thanks guys ! You're too fast for me ... I'm trying to catch up with
the emails ... I was just answering a previous email from Costin and you
come up with the result !
Just to let me understand what you're saying ...
Are you saying that the logic in Tomcat is that prior to closing a
socket, all data is read first ?
And that this is not what is happening here ?
And thus if I changed my test case to explicitly tell Tomcat to read the
body (using request.getParameter(xxx)) the problem will disappear ?
Could it be because for this test case (testPostMethod) HTTP parameters
are sent both in the URL _and_ in the body as POST data ?
Thanks a lot
-Vincent
-Original Message-
From: Bill Barker [mailto:[EMAIL PROTECTED]]
Sent: 07 February 2002 21:38
To: Tomcat Developers List
Subject: Re: Tomcat 3.3 - Cactus Issue
I've found an XP machine to try this on, and can pretty much confirm
that
it
is an un-read POST body. The print statements show that the bad test
has
(at the end):
Content-Length: 11
Available:11
The servlet is finishing so fast that the body isn't even available by
the
time shutdownInput is called. If I modify TcpConnection.shutdownInput
to
do:
socket.setSoTimeout(10);
InputStream is = socket.getInputStream();
int available = is.available ();
if(available = 0) {
available=1;
}
Cactus starts working (although all of the times are increased by
10ms).
Interestingly, Socket.shutdownInput() still causes Cactus to fail.
The
thread yielding logic needs to be moved up to before the call to
shutdownInput to get it to work.
- Original Message -
From: [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Thursday, February 07, 2002 9:05 AM
Subject: RE: Tomcat 3.3 - Cactus Issue
On Thu, 7 Feb 2002, Vincent Massol wrote:
The particularity of testPostMethod is that it sends information
both
in
the URL (as parameters) and in the request BODY in POST form.
Thus, there is some POST data sent !
Ok, then what really matters is who reads the body and how.
Sorry for not beeing able to spend more time on this, I wanted to
finish the password for ajp13 ( I think it's pretty important to
at least have the code in ).
Larry - since you spent a lot of time on this, did you checked
the values for getContentLenght() and request.available - that
would be an easy indication of how much has been read from
the body.
Vincent - could you add a println or debug message in the method
that is doing the POST - with the exact size of the body.
Do you set Content-Length header ? Are you using URLConnection
to send the body, or a custom http client.
I still have a feeling something is wrong with the request
body. All the references I found about this exception are related
with unread data on the receiving socket - and the fact that
it happens only sometimes and on some OSes indicates pretty
clearly that somehow some data is still 'on the wire' when
we close the socket ( and gets in after available() ).
If the ContentLength and the read size of the body you send
do match - then checking getContentLength() and available
would clearly show if the servlet is indeed reading the full
body ( and we would know that the sender is not sending more ).
Would it be possible to have a difference between the 2 ?
Like having ContentLength set to a string size, and
some non-ascii chars in the string ?
Costin
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:tomcat-dev-
[EMAIL PROTECTED]
For additional commands, e-mail: mailto:tomcat-dev-
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 - Cactus Issue
Ok, I do now understand ... Thank you very much and sorry for the fright ! ;-) Last thing I'd like to confirm : When data is sent over a socket, it will fill the socket buffer (at the client side) and then sending of data will block until the server side reads from the socket buffer ? If the server closes the socket and there is data in the socket buffer, on the client side, the client socket will report an exception. Is that correct ? Thanks. -Vincent BTW, I've tried reading the body with getParameter() and effectively the error does not happen any more. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 07 February 2002 22:47 To: Tomcat Developers List Subject: RE: Tomcat 3.3 - Cactus Issue On Thu, 7 Feb 2002, Larry Isaacs wrote: Many thanks for finding this. Not suprisingly Costin's initial guess was correct. Fortunately I wasn't wrong about one assumption, which was the reason for the failure was that Tomcat 3.3 was too fast. Thanks again, to Costin. Well, given the amount of time I had to spend to fix the CRLF POST bug, it's not something I'll forget soon. It's not often that you get to look with tcpdump at each packet for a week and get back to the tcp spec. I had a bit of panic when I saw this problem - it's very painful to debug this kind of problems, and my hope was that I finally understood how tcp works... BTW, we should keep the sleep() as an option - it's scarry that tomcat is processing the request faster than the OS can send data... We need to add at least 100ms to each request. Costin -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt
-Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED]] Sent: 05 February 2002 06:44 To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt Issue Description 1 Must be able to compile and run under JDK 1.1.8 + FIXED 2 Address Cactus failures running with Tomcat 3.3 + Tried but not 100% successful yet. From what little I've seen, I've never really understood this one. The so we're 2 ;-). What I don't understand is why Cactus tests run fine on all servlet containers (including Tomcat 3.2.x and Tomcat 4.x) except for Tomcat 3.3.x ! Request runs under a single thread, so yielding shouldn't do anything at all (unless the Cactus servlet starts a thread, in which case it is a Cactus problem). Cactus is not starting any thread. I can see where increasing SoLinger might help, but 0.1 Sec should be plenty with an up-to-date machine. Does the problem appear when you don't use the HTTP connector? How could I test this as I need to HTTP connector to call the Cactus servlet ? Thanks Bill, -Vincent -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 - Cactus Issue
Larry, See below. -Original Message- From: Larry Isaacs [mailto:[EMAIL PROTECTED]] Sent: 05 February 2002 19:03 To: 'Tomcat Developers List' Subject: RE: Tomcat 3.3 - Cactus Issue Comments below. [snip] Let me know if that helps - and if not what's the easiest way to reproduce ( I don't use Windows, but I can find a system with W2000, not sure about XP ) I'll see if I can verify if there is any extra input coming from the client. To reproduce, I get the Cactus source and with appropriate build.properties files, I build the clean, jar, and sample targets. I then create/copy a build.properties file to the ../target/servlet22/dist/sample/build and run the tests_tomcat_33 target. There are some additional jars to add to Ant's lib directory, but I don't have that list off the top of my head. Let me know if you need any additional specifics. To run the Cactus tests, the simplest is to : - create a build.properties file in build/ (you can use the build.properties.sample as a template). Make sure you define tomcat.home.33 - simply type 'ant tests' That's all. Cheers, Larry thanks -Vincent -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Servlet Unit Testing strategies
Hi Tomcat developers, I'd like to have your opinion on servlet unit testing. I have written a simple extension to JUnit called J2EEUnit to do that but I'd like to knwo if there is a general consensus on servlet unit testing, regarding it's usefulness : Do you think : 1) It is useless. Just need to put a good facade in front of your business code and for the remaining part related to Servlets, functional tests are fine (using a tool such as HttpUnit), 2) It is nice to be able to unit test the part of the code related to servlets (i.e. the controller in a MVC model).It is possible to come up with a tool to do that (ex: J2EEUnit) 3) With the current servlet API it is not possible to come up with a framework that will let you properly do unit tests. It will have lots of shortcomings. The only solution is to extend the Servlet API by our own Servlet Test API. Then have Tomcat implement it. Once we have this, it will then be possible to create a tool/framework that make use of this Test API to unit test servlet. The next step will to promote this API so that it becomes a standard and other Servlet engine implement it. For point 3), are you aware of any project/discussion/JSR on the subject ? Thanks a lot. Vincent Massol J2EEUnit author - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Tomcat 4.0 ServletOutputStream and Serialized object problem
Hi,
The following simple code does not seem to work
with Tomcat 4.0beta1. I just try to send a serialized object followed by some
bytes. It works fine with Tomcat 3.1.1, Tomcat 3.2.1, Resin 1.2, Resin 1.3 and
WebLogic 5.1 ... Anyone has a clue ?
---
try
{
OutputStream os = theResponse.getOutputStream();
//
Write back the result object as a serialized
object
ObjectOutputStream oos = new
ObjectOutputStream(os);
oos.writeObject(result);
oos.flush();
// ...
and write back the content from the method under test
(i.e. //
that's everything the method under test has written on
the //
servlet output
stream).
os.write(wrappedResponse.getData());
oos.close();
} catch
(IOException e) {
---
When ran, I get an exception on the server side saying "connection reset by
peer", and on the client side it says "cannot read serialized object".
The code on the client side is :
connection.connect();
ObjectInputStream ois = new
ObjectInputStream(connection.getInputStream());
result = (ServletTestResult)ois.readObject();
Thanks a lot for any hint...
Vincent Massol.
