Re: Tomcat 3.3 repository changes
On Fri, 2002-09-13 at 19:46, Henri Gomez wrote: Now that we have mod_jk present on JTC, what about removing it from TC 3.3.2 CVS ? +1 Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 repository changes
I'm starting to get a little more free time, and will try to put together a plan for Tomcat 3.3.2 in the next few weeks. AFAIK, there is little or no duplication between TC3.3.x's util classes and JTC's util classes. What was moved to JTC has been removed from TC3.3.x. Cheers, Larry -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED]] Sent: Friday, September 13, 2002 5:47 AM To: [EMAIL PROTECTED] Subject: Tomcat 3.3 repository changes Now that we have mod_jk present on JTC, what about removing it from TC 3.3.2 CVS ? Also is it planned to remove util and use only the one present in JTC ? From build/gump it seems that util from JTC will be used but -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 and 4.x tuning via command line
I don't know if the Eclipse configuration allows you to
specify -Dprop=value in Tomcat's startup. If it does,
I think a lot of this can be done in Tomcat 3.3.1 using
parameter substitution. I have used in server.xml
Http10Connector port=${http.port} ... /
and included
-Dhttp.port=8080
in the startup command to make server.xml runtime
configurable. Would this approach work for you?
If so, perhaps it would desirable to add this feature
to Tomcat 4.x.
That seems like a very reasonable approach.
Yes, very good as it will ease the plugin tuning,
everything works fine right now with tomcatpluginv8
for Tomcat 3.3.1-dev
But more generally it will help people who want
to launch multiples tomcat instances from .bat/shell
commands
It should be suffisant in a first and basic approach
to override listen ports.
And of course we could still use a custom server.xml
which could be generated dynamically :
for TC 3.3
java -Dtomcat.home=$TOMCAT_HOME \
org.apache.tomcat.startup.Main start -config /var/site1/server.xml
for TC 4.0 (thanks to correct errors)
java -Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS
-classpath $CLASSPATH \
-Dcatalina.base=$CATALINA_BASE \
-Dcatalina.home=$CATALINA_HOME \
-Djava.io.tmpdir=$CATALINA_TMPDIR \
org.apache.catalina.startup.Bootstrap $@ start -config /var/site1/server.xml
--
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 and 4.x tuning via command line
On Fri, 8 Feb 2002, GOMEZ Henri wrote:
Date: Fri, 8 Feb 2002 09:31:44 +0100
From: GOMEZ Henri [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Subject: RE: Tomcat 3.3 and 4.x tuning via command line
I don't know if the Eclipse configuration allows you to
specify -Dprop=value in Tomcat's startup. If it does,
I think a lot of this can be done in Tomcat 3.3.1 using
parameter substitution. I have used in server.xml
Http10Connector port=${http.port} ... /
and included
-Dhttp.port=8080
in the startup command to make server.xml runtime
configurable. Would this approach work for you?
If so, perhaps it would desirable to add this feature
to Tomcat 4.x.
That seems like a very reasonable approach.
Yes, very good as it will ease the plugin tuning,
everything works fine right now with tomcatpluginv8
for Tomcat 3.3.1-dev
I'm wondering whether we really need to build it in to Tomcat itself,
though. Can't you accomplish the same thing by using a little Ant script
and run a filter or replace task? All this would require is packaging
ant.jar along with Tomcat, or requiring users that need the facility to
download Ant themselves.
Extending this a little further, you could run an Ant style or Anakia
task to convert some internal representation of the server environment you
wish to create into a valid server.xml file for whichever version of
Tomcat you wanted to run ...
Craig
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 and 4.x tuning via command line
I'm wondering whether we really need to build it in to Tomcat itself, though. Can't you accomplish the same thing by using a little Ant script and run a filter or replace task? All this would require is packaging ant.jar along with Tomcat, or requiring users that need the facility to download Ant themselves. Could you give us a little example of ant replace task ? It will be a great interest for the mass :) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 and 4.x tuning via command line
On Fri, 8 Feb 2002, GOMEZ Henri wrote:
Date: Fri, 8 Feb 2002 18:10:57 +0100
From: GOMEZ Henri [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Subject: RE: Tomcat 3.3 and 4.x tuning via command line
I'm wondering whether we really need to build it in to Tomcat itself,
though. Can't you accomplish the same thing by using a little
Ant script
and run a filter or replace task? All this would require
is packaging
ant.jar along with Tomcat, or requiring users that need the facility to
download Ant themselves.
Could you give us a little example of ant replace task ?
It will be a great interest for the mass :)
There's a lot of power in what the replace task can do. Here's a very
simple one that replaces the string @port@ with the port number
specified by the port property:
project name=Create server.xml default=generate
target name=generate description=Generate customized server.xml
replace file=server.xml token=@port@ value=${port}
/target
/project
In your template server.xml, you'd have a Connector element like this:
Connector ... port=@port@ .../
Now, you just run ant -Dport=8085 and you've replaced the port number.
Generalizing this to replace lots of properties is straightforward.
See the Ant docs for more details http://jakarta.apache.org/ant/.
Craig
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 and 4.x tuning via command line
On Fri, 8 Feb 2002, Craig R. McClanahan wrote:
target name=generate description=Generate customized server.xml
replace file=server.xml token=@port@ value=${port}
/target
/project
In your template server.xml, you'd have a Connector element like this:
Connector ... port=@port@ .../
Now, you just run ant -Dport=8085 and you've replaced the port number.
Generalizing this to replace lots of properties is straightforward.
Well, it's a bit more complicated - assuming you want to start multiple
tomcat instances, on different ports ( load balancing for example ),
you'll have ant create different files instead of using one which may be
confusing.
Plus ant will add to the startup time ( which is already high ).
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 and 4.x tuning via command line
There's a lot of power in what the replace task can do.
Here's a very
simple one that replaces the string @port@ with the port number
specified by the port property:
project name=Create server.xml default=generate
target name=generate description=Generate customized
server.xml
replace file=server.xml token=@port@ value=${port}
/target
/project
In your template server.xml, you'd have a Connector element
like this:
Connector ... port=@port@ .../
Now, you just run ant -Dport=8085 and you've replaced the
port number.
Generalizing this to replace lots of properties is straightforward.
Thanks Craig it's a very good example of Ant Power, I will certainly
reuse it for others purposes.
But it won't fit my current need since in my project I have to launch
not less than 20 differents Tomcat instance on the same machine !
TC 3.3 property overriding is more easy to use in such situation and
should be a very usefull feature for TC 4.x.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 and 4.x tuning via command line
I don't know if the Eclipse configuration allows you to
specify -Dprop=value in Tomcat's startup. If it does,
I think a lot of this can be done in Tomcat 3.3.1 using
parameter substitution. I have used in server.xml
Http10Connector port=${http.port} ... /
and included
-Dhttp.port=8080
in the startup command to make server.xml runtime
configurable. Would this approach work for you?
If so, perhaps it would desirable to add this feature
to Tomcat 4.x.
Unfortunately the parameter substitution is broken
in Tomcat 3.3 so you would need 3.3.1 to try this
out.
Cheers,
Larry
-Original Message-
From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 07, 2002 3:28 AM
To: Tomcat Developers List
Subject: Tomcat 3.3 and 4.x tuning via command line
Hi to all,
You should all know that there is a very good Tomcat 3.3/4.0
plugin for the OSS IDE eclipse (www.eclipse.org), available
at http://www.sysdeo.com/eclipse/.
This plugin allow eclipse developper to launch Tomcat from
the IDE, stop, restart and configure many parameters like
tomcat_home. Tomcat could be a binary version installed on
your disk or a project on the IDE, allowing you to debug
it from IDE.
I'm discussing with the plugin developper, Bruno Leroux,
to see if it could be possible to add some functionnalities
to the plugin to defines webapps to be used, which could
be part of the project workbench, and why not override
some of the server.xml settings like http, ajp listen
ports, works and log dir.
And that could be very usefull for eclipse developpers,
but also for sites which could use it to have multiples
instances running in production from a common location,
but with differents settings.
It could allow us to launch many different instances of
Tomcat, a major functionnality found on WebSphere, where
you got a single admin interface which launch many JVM,
on local machine or remote systems, each JVM running a
copy of websphere.
And that could be a real bonus for tomcat, if we later
develop a tomcat launcher service which could do that,
via a native/jni daemon.
In that case we need to add parameters in tomcat command
line (vm or args) to do such overriding.
I was thinking to add parms like :
-override ajp13@8109 -override ajp12@8107 -override http@8180
-override logs@/var/tomcat3/logsxxx -override
works@/var/tomcat3/worksxxx
-addwebapp /var/tomcat3/webappxxx -addwebapp /var/tomcat3/webappyyy
Do you agree on these modifications ?
If so I start to see where to do the modifications on TC 3.3,
some recommandations will be greatly usefull, but who could
the same for TC 4.0 ?
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 and 4.x tuning via command line
I don't know if the Eclipse configuration allows you to
specify -Dprop=value in Tomcat's startup.
Yes you could set any VM and commandline args.
If it does,
I think a lot of this can be done in Tomcat 3.3.1 using
parameter substitution. I have used in server.xml
Http10Connector port=${http.port} ... /
and included
-Dhttp.port=8080
Excellent, where could I take a look at it .
in the startup command to make server.xml runtime
configurable. Would this approach work for you?
Yes
If so, perhaps it would desirable to add this feature
to Tomcat 4.x.
May be
Unfortunately the parameter substitution is broken
in Tomcat 3.3 so you would need 3.3.1 to try this
out.
Where could I take more information on these feature in
3.3.1 ?
--
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 and 4.x tuning via command line
It is described in the Variable substitution section
near the top of the serverxml.html document.
http://jakarta.apache.org/tomcat/tomcat-3.3-doc/serverxml.html
Cheers,
Larry
-Original Message-
From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 07, 2002 7:53 AM
To: Tomcat Developers List
Subject: RE: Tomcat 3.3 and 4.x tuning via command line
I don't know if the Eclipse configuration allows you to
specify -Dprop=value in Tomcat's startup.
Yes you could set any VM and commandline args.
If it does,
I think a lot of this can be done in Tomcat 3.3.1 using
parameter substitution. I have used in server.xml
Http10Connector port=${http.port} ... /
and included
-Dhttp.port=8080
Excellent, where could I take a look at it .
in the startup command to make server.xml runtime
configurable. Would this approach work for you?
Yes
If so, perhaps it would desirable to add this feature
to Tomcat 4.x.
May be
Unfortunately the parameter substitution is broken
in Tomcat 3.3 so you would need 3.3.1 to try this
out.
Where could I take more information on these feature in
3.3.1 ?
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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.
Does the latest 3.3.1-dev still fails on your laptop in
spite a recent change to dump unread charecters?
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 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]
--
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
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:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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 and 4.x tuning via command line
On Thu, 7 Feb 2002, GOMEZ Henri wrote: Date: Thu, 7 Feb 2002 09:28:01 +0100 From: GOMEZ Henri [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Tomcat 3.3 and 4.x tuning via command line Hi to all, You should all know that there is a very good Tomcat 3.3/4.0 plugin for the OSS IDE eclipse (www.eclipse.org), available at http://www.sysdeo.com/eclipse/. This plugin allow eclipse developper to launch Tomcat from the IDE, stop, restart and configure many parameters like tomcat_home. Tomcat could be a binary version installed on your disk or a project on the IDE, allowing you to debug it from IDE. I'm discussing with the plugin developper, Bruno Leroux, to see if it could be possible to add some functionnalities to the plugin to defines webapps to be used, which could be part of the project workbench, and why not override some of the server.xml settings like http, ajp listen ports, works and log dir. And that could be very usefull for eclipse developpers, but also for sites which could use it to have multiples instances running in production from a common location, but with differents settings. It could allow us to launch many different instances of Tomcat, a major functionnality found on WebSphere, where you got a single admin interface which launch many JVM, on local machine or remote systems, each JVM running a copy of websphere. And that could be a real bonus for tomcat, if we later develop a tomcat launcher service which could do that, via a native/jni daemon. In that case we need to add parameters in tomcat command line (vm or args) to do such overriding. I was thinking to add parms like : -override ajp13@8109 -override ajp12@8107 -override http@8180 -override logs@/var/tomcat3/logsxxx -override works@/var/tomcat3/worksxxx -addwebapp /var/tomcat3/webappxxx -addwebapp /var/tomcat3/webappyyy Do you agree on these modifications ? This doesn't seem like a very scalable approach. It appears, for example, that the only thing you can override about a connector is which port it's on. What happens if you want to override, say, the maximum number of connections that your connector will accept (the maxProcessors parameter on Tomcat 4's HttpConnector)? Wouldn't it be easier to build a launcher that wrapped the EmbededTomcat (3.x) or Embedded (4.x) class instead, if you don't want to modify server.xml? If so I start to see where to do the modifications on TC 3.3, some recommandations will be greatly usefull, but who could the same for TC 4.0 ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] Craig McClanahan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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]
RE: Tomcat 3.3 and 4.x tuning via command line
On Thu, 7 Feb 2002, Larry Isaacs wrote:
Date: Thu, 7 Feb 2002 07:40:21 -0500
From: Larry Isaacs [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: 'Tomcat Developers List' [EMAIL PROTECTED]
Subject: RE: Tomcat 3.3 and 4.x tuning via command line
I don't know if the Eclipse configuration allows you to
specify -Dprop=value in Tomcat's startup. If it does,
I think a lot of this can be done in Tomcat 3.3.1 using
parameter substitution. I have used in server.xml
Http10Connector port=${http.port} ... /
and included
-Dhttp.port=8080
in the startup command to make server.xml runtime
configurable. Would this approach work for you?
If so, perhaps it would desirable to add this feature
to Tomcat 4.x.
That seems like a very reasonable approach.
Unfortunately the parameter substitution is broken
in Tomcat 3.3 so you would need 3.3.1 to try this
out.
Cheers,
Larry
Craig
-Original Message-
From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 07, 2002 3:28 AM
To: Tomcat Developers List
Subject: Tomcat 3.3 and 4.x tuning via command line
Hi to all,
You should all know that there is a very good Tomcat 3.3/4.0
plugin for the OSS IDE eclipse (www.eclipse.org), available
at http://www.sysdeo.com/eclipse/.
This plugin allow eclipse developper to launch Tomcat from
the IDE, stop, restart and configure many parameters like
tomcat_home. Tomcat could be a binary version installed on
your disk or a project on the IDE, allowing you to debug
it from IDE.
I'm discussing with the plugin developper, Bruno Leroux,
to see if it could be possible to add some functionnalities
to the plugin to defines webapps to be used, which could
be part of the project workbench, and why not override
some of the server.xml settings like http, ajp listen
ports, works and log dir.
And that could be very usefull for eclipse developpers,
but also for sites which could use it to have multiples
instances running in production from a common location,
but with differents settings.
It could allow us to launch many different instances of
Tomcat, a major functionnality found on WebSphere, where
you got a single admin interface which launch many JVM,
on local machine or remote systems, each JVM running a
copy of websphere.
And that could be a real bonus for tomcat, if we later
develop a tomcat launcher service which could do that,
via a native/jni daemon.
In that case we need to add parameters in tomcat command
line (vm or args) to do such overriding.
I was thinking to add parms like :
-override ajp13@8109 -override ajp12@8107 -override http@8180
-override logs@/var/tomcat3/logsxxx -override
works@/var/tomcat3/worksxxx
-addwebapp /var/tomcat3/webappxxx -addwebapp /var/tomcat3/webappyyy
Do you agree on these modifications ?
If so I start to see where to do the modifications on TC 3.3,
some recommandations will be greatly usefull, but who could
the same for TC 4.0 ?
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 and 4.x tuning via command line
It appears, for example, that the only thing you can override about a connector is which port it's on. What happens if you want to override, say, the maximum number of connections that your connector will accept (the maxProcessors parameter on Tomcat 4's HttpConnector)? Right +1 for you here Wouldn't it be easier to build a launcher that wrapped the EmbededTomcat (3.x) or Embedded (4.x) class instead, if you don't want to modify server.xml? May be, another approach could be server.xml generated dynamically by launcher app and passed as parameter. If so I start to see where to do the modifications on TC 3.3, some recommandations will be greatly usefull, but who could the same for TC 4.0 ? What do you think about that for TC 4.0 ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 - Cactus Issue
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 07, 2002 12:06 PM To: Tomcat Developers List 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. I had not checked getContentLength(). I'll see what I can find out. Since I'm not able to duplicate the Windows failure, I'll try to make some customized jars that Vincent can try to gather more clues. 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:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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:[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
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.
I'll see about moving the yielding logic tonight and then
tag 3.3.1-beta1 and begin staging the beta1 release.
Cheers,
Larry
-Original Message-
From: Bill Barker [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 07, 2002 4:38 PM
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:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 - Cactus Issue
On Thu, 7 Feb 2002, Vincent Massol wrote: Are you saying that the logic in Tomcat is that prior to closing a socket, all data is read first ? No, tomcat will just try to flush it's input buffers. We don't want to read all data - the servlet is supposed to process the request and decide if it wants to read the body or not. If it's a POST and getParameter() is called, we read the body for the user. If the user calls getInputStream(), he can read as much as he wants ( he may read the first bytes and decide it doesn't care for the file ). If for any reason the servlet hasn't read the full body ( either a POST where getParameter() is not called, or an input stream that is not completely read ), tomcat will discard the rest. Maybe you're in a DOS, or doing a large upload and the servlet doesn't want it - no need to load the network. The code is just trying to read whatever is still in the buffer ( received from net but not processed by java, so still in the OS TCP stack ). If you have data in the OS TCP stack, it'll send an ABORT packet to signal to the other end the error condition ( so the other side will know that some of the data it sent was not processed ). IMHO the correct behavior is to _do_ send the ABORT, because that will allow the user to know what happened. But many OSes just ignore the ABORT or don't send it. And thus if I changed my test case to explicitly tell Tomcat to read the body (using request.getParameter(xxx)) the problem will disappear ? I'm pretty sure of that. Or read the full body. Or catch the exception, as it is a correct response from tomcat indicating the body didn't reached the target ( the servlet ). Could it be because for this test case (testPostMethod) HTTP parameters are sent both in the URL _and_ in the body as POST data ? Definitely no - I'm pretty sure we deal with that, and we have few good tests. We can even deal with a servlet that reads some data using input stream and then call getParameter(). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 3.3 - Cactus Issue
See inline.
- Original Message -
From: Vincent Massol [EMAIL PROTECTED]
To: 'Tomcat Developers List' [EMAIL PROTECTED]
Sent: Thursday, February 07, 2002 1:57 PM
Subject: 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 ?
Yes, provided that it can be read without blocking (which isn't the case
here).
And that this is not what is happening here ?
The Client is finishing before the body has arrived.
And thus if I changed my test case to explicitly tell Tomcat to read the
body (using request.getParameter(xxx)) the problem will disappear ?
Correct. Then Tomcat will read the body (blocking until it comes).
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]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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:[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: 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:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 3.3 - Cactus Issue
Hi Larry,
We had a similar problem long time ago - with the POST and the extra
CRLF. While investigating it, I found a lot of interesting stuff
about Connection reset by peer :-)
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.
This is the correct behavior, as it signal the sending side that
whatever it has in the send buffers will be lost. It will
happen if tomcat doesn't receive the full POST data - it used
to be the extra CRLF that some browsers sent ( above
the Content-Length limit ).
The first thing I would check is if the full body was read -
we already have the workaround for the CRLF bug in TcpConnection,
but it is possible something is wrong there.
Looking at the code, it may be possible that after
while( available 0 ) { is.skip(), available=is.availabe() }
we may receive some more data.
That's likely to happen on a fast system, and a sleep before
close() would make it more likely.
The code was supposed to deal with 2 bytes of extra data ( the
CRLF ), not with some POST body that is supposed to be ignored,
so it isn't implementing a 'correct' socket.shutdownInput().
One thing to try is to use the JDK1.3 socket.shutdownInput()
instead ( with a Jdk11Compat workwaround ).
I see no good way to implement this - doesn't matter what
we do, between reading/skiping data that is available and
calling close() it is allwasy possible we'll receive more
data ( we can't 'sync' or anything like that ). It is likely
the threading model affects that - probably is.available()
call yields on some OSes, giving the sender an extra chance to
send more data.
A solution would be to read/ignore the full post body - but that
is very bad in case of large bodies ( that the servlet may
decide to ignore ), and for DOS.
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 )
Costin
On Tue, 5 Feb 2002, Larry Isaacs wrote:
Hi Bill,
Here are the details of the problem with Tomcat 3.3 and Cactus.
Apparently, Cactus's sample test suite run against Tomcat 3.3 will
occasionally fail on the main Gump system (a 300Mhz system running
Linux) and reliably fails Vincent Massol's laptop (1Gig+ system
running Windows XP). The failure is the same for both. In the
testPostMethod test, the following exception is thrown on by the
Cactus client:
java.net.SocketException: Connection aborted by peer: JVM_recv in
socket input stream read
at java.net.SocketInputStream.socketRead(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:86)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:186)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:225)
at java.io.BufferedInputStream.read(BufferedInputStream.java:280)
at java.io.FilterInputStream.read(FilterInputStream.java:114)
at java.io.PushbackInputStream.read(PushbackInputStream.java:164)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:649)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:613)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:621)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream
(HttpURLConnection.java:506)
at org.apache.cactus.client.AutoReadHttpURLConnection.getInputStream
(AutoReadHttpURLConnection.java;
org/apache/cactus/util/log/LogAspect.java(1k):123)
at org.apache.cactus.client.AbstractHttpClient.callRunTest
(AbstractHttpClient.java;
org/apache/cactus/util/log/LogAspect.java(1k):192)
at org.apache.cactus.client.AbstractHttpClient.doTest$ajcPostAround10
(AbstractHttpClient.java;
org/apache/cactus/util/log/LogAspect.java(1k):119)
at org.apache.cactus.client.AbstractHttpClient.doTest
(AbstractHttpClient.java;
org/apache/cactus/util/log/LogAspect.java(1k):1204)
at org.apache.cactus.AbstractTestCase.runGenericTest
(AbstractTestCase.java:437)
at org.apache.cactus.ServletTestCase.runTest(ServletTestCase.java:130)
at org.apache.cactus.AbstractTestCase.runBare(AbstractTestCase.java:385)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:131)
at junit.framework.TestSuite.runTest(TestSuite.java:173)
at junit.framework.TestSuite.run(TestSuite.java:168)
at junit.framework.TestSuite.runTest(TestSuite.java:173)
at junit.framework.TestSuite.run(TestSuite.java:168)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run
(JUnitTestRunner.java:231)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main
RE: Tomcat 3.3 - Cactus Issue
Comments below.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 05, 2002 12:45 PM
To: Tomcat Developers List
Subject: Re: Tomcat 3.3 - Cactus Issue
Hi Larry,
We had a similar problem long time ago - with the POST and the extra
CRLF. While investigating it, I found a lot of interesting stuff
about Connection reset by peer :-)
The best I can tell, no POST data is sent and none is read, so I
have been assuming this isn't the problem.
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.
This is the correct behavior, as it signal the sending side that
whatever it has in the send buffers will be lost. It will
happen if tomcat doesn't receive the full POST data - it used
to be the extra CRLF that some browsers sent ( above
the Content-Length limit ).
The first thing I would check is if the full body was read -
we already have the workaround for the CRLF bug in TcpConnection,
but it is possible something is wrong there.
Looking at the code, it may be possible that after
while( available 0 ) { is.skip(), available=is.availabe() }
we may receive some more data.
I believe this code is newer than the last official failure
I heard of from Vincent. I think this was:
if (available 1) {
is.skip (available);
}
prior to Bill's recent commit to TcpConnection.java.
That's likely to happen on a fast system, and a sleep before
close() would make it more likely.
The code was supposed to deal with 2 bytes of extra data ( the
CRLF ), not with some POST body that is supposed to be ignored,
so it isn't implementing a 'correct' socket.shutdownInput().
One thing to try is to use the JDK1.3 socket.shutdownInput()
instead ( with a Jdk11Compat workwaround ).
I see no good way to implement this - doesn't matter what
we do, between reading/skiping data that is available and
calling close() it is allwasy possible we'll receive more
data ( we can't 'sync' or anything like that ). It is likely
the threading model affects that - probably is.available()
call yields on some OSes, giving the sender an extra chance to
send more data.
A solution would be to read/ignore the full post body - but that
is very bad in case of large bodies ( that the servlet may
decide to ignore ), and for DOS.
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.
Cheers,
Larry
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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 ? 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:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 - Cactus Issue
Vincent: is your test servlet reading the body i.e. calls getParameters() if it's a url-encoded body, or read the full stream ? 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. 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. Cheers, Larry -- 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]
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:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 - Cactus Issue
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 05, 2002 2:46 PM To: Tomcat Developers List Subject: RE: Tomcat 3.3 - Cactus Issue On Tue, 5 Feb 2002, Larry Isaacs wrote: One question - with the sleep(), do you do an isAvailable()/skip() after the sleep ? Didn't try is.available() after the sleep. I can try that. Larry -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 - Cactus Issue
I tried adding a Thread.sleep(1) just before the call to TcpConnection.shutdownInput() in Http10Interceptor. A System.out.println() within shutdownInput's while never prints during a successful Cactus run on Win2k. Is there anything different I should try? Larry -Original Message- From: Larry Isaacs Sent: Tue 2/5/2002 2:56 PM To: 'Tomcat Developers List' Cc: Subject: RE: Tomcat 3.3 - Cactus Issue -Original Message- From: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 05, 2002 2:46 PM To: Tomcat Developers List Subject: RE: Tomcat 3.3 - Cactus Issue On Tue, 5 Feb 2002, Larry Isaacs wrote: One question - with the sleep(), do you do an isAvailable()/skip() after the sleep ? Didn't try is.available() after the sleep. I can try that. Larry msg21385/bin0.bin Description: application/ms-tnef -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 - Cactus Issue
On Tue, 5 Feb 2002, Larry Isaacs wrote: I tried adding a Thread.sleep(1) just before the call to TcpConnection.shutdownInput() in Http10Interceptor. A System.out.println() within shutdownInput's while never prints during a successful Cactus run on Win2k. Is there anything different I should try? It seems I was wrong, it may be a different problem. I'll try to reproduce it. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 getRemoteHost always returns localHost - Is there any 3.3 production version has patch applied
See my reply on tomcat-user. Cheers, Larry -Original Message- From: Jayakumar Duraisamy [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 3:04 PM To: [EMAIL PROTECTED] Subject: FW: Tomcat 3.3 getRemoteHost always returns localHost - Is there any 3.3 production version has patch applied May i know when the production release for this fix is in schedule. Thanks and Regards Jayakumar -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 2:25 PM To: Tomcat Users List Subject: RE: Tomcat 3.3 getRemoteHost always returns localHost - Is there any 3.3 production version has patch applied Use the cvs version. Works perfectly fine in production environments and is very stable.. (running here without any problems) Mvgr, Martin -Original Message- From: Jayakumar Duraisamy [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 20:22 To: [EMAIL PROTECTED] Subject: Tomcat 3.3 getRemoteHost always returns localHost - Is there any 3.3 production version has patch applied We have moved from tomcat 3.2.1 to 3.3. We have one of our functionality depend on identifying the client based on the client IP/Hostname. In 3.2.1 ServletRequest.getRemoteHost() returns the DHCP address for the client, where as in 3.3 it always returns as localhost. I have seen a bug no 3944 reported and the status says that it is fixed in 3.3 Release Candidate 1. I downloaded the nightly build 3.3.1 Dev and tested for the bug. It looks fine and now returns the DHCP address. My question is which production release has this patch [Except 4.0, i am interested in 3.3.X]. If not, WHEN CAN I EXPECT THIS RELEASE. Thanks in advance Jayakumar -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 3.3 deployment - last minute problem
Hi all, i also investigating this problem a little bit, my solution to this is use a filter to convert all the income request's data to UTF8. and generate JSP by UTF8 encoding. it work quite good. but the problem is my backend database must have UTF8 support From Timothy - Original Message - From: Renato [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, December 18, 2001 6:27 PM Subject: Re: Tomcat 3.3 deployment - last minute problem Hi all, I'm investigating this problem and may found something. The html that is pushed to my browser is definitely pure Unicode ( UTF8 ), so somehow the HTML bytes are not been properly translated to chars. Where can I look in the code to make some tests ? Thanks Renato. Reply-to: Tomcat Developers List From: Renato Date: Fri Dec 14 15:19:28 2001 To: Tomcat Developers List , Tomcat Developers List , , Subject: Re: Tomcat 3.3 deployment - last minute problem Hi, This is what I'm using: I saw the servlet generated in the work directory and it actually write the response.setContentType(text/html;charset=ISO-8859-1) ( default type in server.xml is set to ISO-8859-1 too ) How can I know the charset of Linux ? ( I'll STW of course.. :)) ) Thanks for the promptness ! On Fri, 14 Dec 2001 08:48:31 -0800 (PST), escreveu : On Fri, 14 Dec 2001, Renato wrote: *** HTML pages with latin characters don't display correctly on Linux *** ( JSP file with: ) Ex: áéÃóú It's maybe a problem with the locale variables on my Linux, which I don't quite understand ( tried LC_ALL, LANG, LC_CTYPE and it didn't work ) or Tomcat itself. Do you set the charset in the page setContentType(text/html;charset=8859-??) or the jsp equivalent ? What charset do you use to write the page ? ( i.e. UTF or 8859-?? ) ? There are few variables: - Java default charset ( which is typically the same as the OS charset). This is what jasper uses to read the page from disk. The page is converted to UTF by the reader. ( you can override the charset used on each page, don't remember the directive ) - output charset. This is specified in setContentType() or setCharEncoding on the response, and is used to convert from UTF to the target charset. Costin -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 3.3 deployment - last minute problem
The only thing that I can think of is that your javac doesn't support the -encoding switch. Is it possible that you have an old copy of tools.jar somewhere? Jasper writes out the .java file in UTF8 encoding, which is then passed to javac to compile to a .class. If javac is trying to read the .java file as iso-latin-1, then you'd see something like you're reporting. You might try using Jikes. Tomcat's JspWriter doesn't do any encoding. It just (eventually) passes the chars to the result of calling response.getWriter. This means that the encoding should the same as for a servlet (which you've reported does work). I can't personally reproduce your problem on either Windows or Solaris, so I don't know how much more help I can be. The main files involved are src/facade22/org/apache/tomcat/facade/JspInterceptor.java and src/share/org/apache/jasper/compiler/Compiler.java, if you want to dig through the code. - Original Message - From: Renato [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, December 18, 2001 6:27 PM Subject: Re: Tomcat 3.3 deployment - last minute problem Hi all, I'm investigating this problem and may found something. The html that is pushed to my browser is definitely pure Unicode ( UTF8 ), so somehow the HTML bytes are not been properly translated to chars. Where can I look in the code to make some tests ? Thanks Renato. Reply-to: Tomcat Developers List From: Renato Date: Fri Dec 14 15:19:28 2001 To: Tomcat Developers List , Tomcat Developers List , , Subject: Re: Tomcat 3.3 deployment - last minute problem Hi, This is what I'm using: I saw the servlet generated in the work directory and it actually write the response.setContentType(text/html;charset=ISO-8859-1) ( default type in server.xml is set to ISO-8859-1 too ) How can I know the charset of Linux ? ( I'll STW of course.. :)) ) Thanks for the promptness ! On Fri, 14 Dec 2001 08:48:31 -0800 (PST), escreveu : On Fri, 14 Dec 2001, Renato wrote: *** HTML pages with latin characters don't display correctly on Linux *** ( JSP file with: ) Ex: áéÃóú It's maybe a problem with the locale variables on my Linux, which I don't quite understand ( tried LC_ALL, LANG, LC_CTYPE and it didn't work ) or Tomcat itself. Do you set the charset in the page setContentType(text/html;charset=8859-??) or the jsp equivalent ? What charset do you use to write the page ? ( i.e. UTF or 8859-?? ) ? There are few variables: - Java default charset ( which is typically the same as the OS charset). This is what jasper uses to read the page from disk. The page is converted to UTF by the reader. ( you can override the charset used on each page, don't remember the directive ) - output charset. This is specified in setContentType() or setCharEncoding on the response, and is used to convert from UTF to the target charset. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 3.3 deployment - last minute problem
Hi Bill, Thanks for the help. I found out the problem. It was jikes. I was using jikes in the JspInterceptor and somewhat it wasn't working. Now, I will upgrade all my user base to Tomcat 3.3 :)) Renato. On Tue, 18 Dec 2001 14:29:24 -0800, Bill Barker [EMAIL PROTECTED] escreveu : The only thing that I can think of is that your javac doesn't support the -encoding switch. Is it possible that you have an old copy of tools.jar somewhere? Jasper writes out the .java file in UTF8 encoding, which is then passed to javac to compile to a .class. If javac is trying to read the .java file as iso-latin-1, then you'd see something like you're reporting. You might try using Jikes. Tomcat's JspWriter doesn't do any encoding. It just (eventually) passes the chars to the result of calling response.getWriter. This means that the encoding should the same as for a servlet (which you've reported does work). I can't personally reproduce your problem on either Windows or Solaris, so I don't know how much more help I can be. The main files involved are src/facade22/org/apache/tomcat/facade/JspInterceptor.java and src/share/org/apache/jasper/compiler/Compiler.java, if you want to dig through the code. - Original Message - From: Renato [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, December 18, 2001 6:27 PM Subject: Re: Tomcat 3.3 deployment - last minute problem Hi all, I'm investigating this problem and may found something. The html that is pushed to my browser is definitely pure Unicode ( UTF8 ), so somehow the HTML bytes are not been properly translated to chars. Where can I look in the code to make some tests ? Thanks Renato. Reply-to: Tomcat Developers List From: Renato Date: Fri Dec 14 15:19:28 2001 To: Tomcat Developers List , Tomcat Developers List , , Subject: Re: Tomcat 3.3 deployment - last minute problem Hi, This is what I'm using: I saw the servlet generated in the work directory and it actually write the response.setContentType(text/html;charset=ISO-8859-1) ( default type in server.xml is set to ISO-8859-1 too ) How can I know the charset of Linux ? ( I'll STW of course.. :)) ) Thanks for the promptness ! On Fri, 14 Dec 2001 08:48:31 -0800 (PST), escreveu : On Fri, 14 Dec 2001, Renato wrote: *** HTML pages with latin characters don't display correctly on Linux *** ( JSP file with: ) Ex: áéÃóú It's maybe a problem with the locale variables on my Linux, which I don't quite understand ( tried LC_ALL, LANG, LC_CTYPE and it didn't work ) or Tomcat itself. Do you set the charset in the page setContentType(text/html;charset=8859-??) or the jsp equivalent ? What charset do you use to write the page ? ( i.e. UTF or 8859- ?? ) ? There are few variables: - Java default charset ( which is typically the same as the OS charset). This is what jasper uses to read the page from disk. The page is converted to UTF by the reader. ( you can override the charset used on each page, don't remember the directive ) - output charset. This is specified in setContentType() or setCharEncoding on the response, and is used to convert from UTF to the target charset. 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 deployment - last minute problem
Hi, This is what I'm using: %@ page contentType=text/html; charset=ISO-8859-1 % I saw the servlet generated in the work directory and it actually write the response.setContentType(text/html;charset=ISO-8859-1) ( default type in server.xml is set to ISO-8859-1 too ) How can I know the charset of Linux ? ( I'll STW of course.. :)) ) Thanks for the promptness ! On Fri, 14 Dec 2001 08:48:31 -0800 (PST), [EMAIL PROTECTED] escreveu : On Fri, 14 Dec 2001, Renato wrote: *** HTML pages with latin characters don't display correctly on Linux *** ( JSP file with: ) Ex: páéÃóú/p It's maybe a problem with the locale variables on my Linux, which I don't quite understand ( tried LC_ALL, LANG, LC_CTYPE and it didn't work ) or Tomcat itself. Do you set the charset in the page setContentType(text/html;charset=8859-??) or the jsp equivalent ? What charset do you use to write the page ? ( i.e. UTF or 8859-?? ) ? There are few variables: - Java default charset ( which is typically the same as the OS charset). This is what jasper uses to read the page from disk. The page is converted to UTF by the reader. ( you can override the charset used on each page, don't remember the directive ) - output charset. This is specified in setContentType() or setCharEncoding on the response, and is used to convert from UTF to the target charset. 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 deployment - last minute problem
On Fri, 14 Dec 2001, Renato wrote: *** HTML pages with latin characters don't display correctly on Linux *** ( JSP file with: ) Ex: páéÃóú/p It's maybe a problem with the locale variables on my Linux, which I don't quite understand ( tried LC_ALL, LANG, LC_CTYPE and it didn't work ) or Tomcat itself. Do you set the charset in the page setContentType(text/html;charset=8859-??) or the jsp equivalent ? What charset do you use to write the page ? ( i.e. UTF or 8859-?? ) ? There are few variables: - Java default charset ( which is typically the same as the OS charset). This is what jasper uses to read the page from disk. The page is converted to UTF by the reader. ( you can override the charset used on each page, don't remember the directive ) - output charset. This is specified in setContentType() or setCharEncoding on the response, and is used to convert from UTF to the target charset. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 3.3 (JDK 1.1 compatibility fixes)
Any news on this one James ? Do you have any patch that could add jar:
support to SimpleClassLoader ? We could implement a workaround, but if
possible I would fix this by supporing jar URLs where not available.
Costin
On Fri, 7 Sep 2001, James THOMAS wrote:
I'm using IBM's JDK 1.1.8
I feel almost certain that it does not have a jar protocol handler.
I tried your suggestion but I still get the exception:
java.net.MalformedURLException: unknown protocol: jar
at java.lang.Throwable.init(Throwable.java:74)
at java.lang.Exception.init(Exception.java:38)
at java.io.IOException.init(IOException.java:38)
at
java.net.MalformedURLException.init(MalformedURLException.java:38)
at java.net.URL.init(URL.java:201)
at java.net.URL.init(URL.java:222)
Looking at JDK 1.1.8 javadoc it seems that a URL Handler for the protocol
is created:
If this is the first URL object being created with the specified
protocol, a stream protocol handler object, an instance of class
URLStreamHandler, is created for that protocol:
James
==
==
Thanks again James.
I think I understand now.
First question - what VM are you using ? JDK1.1.8 ( Sun and IBM ) seem to
have handlers for jar protocol ( even if it's not standard AFAIK ). Long
time ago I tested with kaffe and it worked - but I'm not sure I tested
getResource().
The real problem is not in DependClassLoader, but SimpleClassLoader, where
getResource() is implemented. Even if we 'hack' DCL to not call
getResource(), I think it would be better, as you sugest, to add code to
support the jar protocol.
The problem is in SCL.getResource(), the code is:
// a jar:-URL *could* change even between minor releases, but
// didn't between JVM's 1.1.6 and 1.3beta. Tested on JVM's from
// IBM, Blackdown, Microsoft, Sun @ Windows and Sun @ Solaris
if( r.zipEntry != null ) {
try {
return new URL(jar:file: +
r.repository.getPath() + !/ +
name);
} catch(java.net.MalformedURLException badurl) {
One thing you can try ( and may work ) is to replace this with
new URL(jar, null, r.repository.getPath() + !/ + name );
This will avoid calling the handlers ( which are used to parse the local
part ).
I agree the right solution is to add the dummy handler ( or a 'real' jar
handler ! ) in the compat package. It must at least parse the URL,
otherwise it'll brake reloading ( since getFile() is used to add the jar
location to the list of files that are checked for modifications ).
Costin
On Fri, 7 Sep 2001, James THOMAS wrote:
Thanks for the great info Costin.
Just an FYI, I did implement another solution, which was to implement a
Handler class for the jar protocol. Interestingly enough, it was
sufficient to only have a class that is responsible for the jar
protocol.
The implementation of the class could be crap because it is never used.
The explanation behind this is implementation of the DependClassLoader:
Basic Algorithm of loadClassInternal:
1) If class is already loaded, return it.
2) obtain the class as a resource from parent (but will don't construct
the Class yet). If the resource is not found, then throw a
ClassNotFoundException. This is where we are failing today because the
jar protocol does not have a handler in JDK 1.1
3) load the class from parent2 and return it if found.
4) no create the class from the resource loaded in step 2
By having a handler for the jar protocol, we get a non-null URL in step
2, thus avoiding the ClassNotFoundException. And in my testing,
parent2
was always able to load the class requested. Thus, the resource (i.e.
URL)
obtained from step 2 was never used.
===
===
Thanks James, I'm very happy to see your contributions. ( and my
appologies for not testing with 1.1 often enough ).
jakarta-tomcat-3.3-dev-src\src\share\org\apache\tomcat\util\depend\DependClassLoader.java
==
The method loadClassInternal appears to be incorrect. When loading a
class, the code first retrieves the class as a resource from the
parent
class loader. But, the return value from the getResource is not used
because the code then delegates the class loading to the parent2
class
loader (parent2.loadClass(name)). When running with JDK 1.1, the
getResource returns null because the jar protocol is not valid (the
exception message unknown protocol: jar is thrown from
SimpleClassLoader
where a
Re: Tomcat 3.3 (JDK 1.1 compatibility fixes)
Thanks for the great info Costin.
Just an FYI, I did implement another solution, which was to implement a
Handler class for the jar protocol. Interestingly enough, it was
sufficient to only have a class that is responsible for the jar protocol.
The implementation of the class could be crap because it is never used.
The explanation behind this is implementation of the DependClassLoader:
Basic Algorithm of loadClassInternal:
1) If class is already loaded, return it.
2) obtain the class as a resource from parent (but will don't construct
the Class yet). If the resource is not found, then throw a
ClassNotFoundException. This is where we are failing today because the
jar protocol does not have a handler in JDK 1.1
3) load the class from parent2 and return it if found.
4) no create the class from the resource loaded in step 2
By having a handler for the jar protocol, we get a non-null URL in step
2, thus avoiding the ClassNotFoundException. And in my testing, parent2
was always able to load the class requested. Thus, the resource (i.e. URL)
obtained from step 2 was never used.
===
===
Thanks James, I'm very happy to see your contributions. ( and my
appologies for not testing with 1.1 often enough ).
jakarta-tomcat-3.3-dev-src\src\share\org\apache\tomcat\util\depend\DependClassLoader.java
==
The method loadClassInternal appears to be incorrect. When loading a
class, the code first retrieves the class as a resource from the parent
class loader. But, the return value from the getResource is not used
because the code then delegates the class loading to the parent2 class
loader (parent2.loadClass(name)). When running with JDK 1.1, the
getResource returns null because the jar protocol is not valid (the
exception message unknown protocol: jar is thrown from
SimpleClassLoader
where a java.net.URL is constructed). This causes the
loadClassInternal
method to throw a ClassNotFoundException prematurely because the class
can successfully be loaded by one of the the parent class loaders. Below
I
offer a solution but I think it would be best if someone with a more
in-depth understanding of the code can validate this solution.
The code is a bit tricky. 3.3 uses normal URLClassLoaders for loading, but
in order to support reloading we use an additional wrapper (
DependClassLoader ) that will collect dependencies ( since a servlet/jsp
can depend on multiple jars/classes ).
For DCL, parent is the webapp class loader. parent2 is the
applications class loader, parent of all webapp loaders.
The code tries to make DependClassLoader as non-intrusive as possible (
i.e. the behavior of using DCL should be as close as possible to 'normal'
).
If a class can be loaded by parent2 ( the common app loader ), then we
just delegate to it ( that's the normal delegation that would be used if
no DCL was present ). We don't delegate to parent because then all classes
loaded as result of resolving the current class would not be registered as
depends ( parent will do all the loading without any notification ).
If not, we'll use parent to get the bytes - then load them. The reason we
have DependClassLoader12 is to support the security context - I couldn't
find any other way ( like via jdkcompat ) since we need to call a
protected method in super.
// check parent class
if( parent != null ) {
try {
c = parent.loadClass( name );
^^^ That will not brake part of reloading - parent will load all classes
that are requested by the current class, and we'll not be able to record
that...
I'll try to find another fix ( nice try ! :-).
Costin
Re: Tomcat 3.3 (JDK 1.1 compatibility fixes)
Thanks again James.
I think I understand now.
First question - what VM are you using ? JDK1.1.8 ( Sun and IBM ) seem to
have handlers for jar protocol ( even if it's not standard AFAIK ). Long
time ago I tested with kaffe and it worked - but I'm not sure I tested
getResource().
The real problem is not in DependClassLoader, but SimpleClassLoader, where
getResource() is implemented. Even if we 'hack' DCL to not call
getResource(), I think it would be better, as you sugest, to add code to
support the jar protocol.
The problem is in SCL.getResource(), the code is:
// a jar:-URL *could* change even between minor releases, but
// didn't between JVM's 1.1.6 and 1.3beta. Tested on JVM's from
// IBM, Blackdown, Microsoft, Sun @ Windows and Sun @ Solaris
if( r.zipEntry != null ) {
try {
return new URL(jar:file: +
r.repository.getPath() + !/ +
name);
} catch(java.net.MalformedURLException badurl) {
One thing you can try ( and may work ) is to replace this with
new URL(jar, null, r.repository.getPath() + !/ + name );
This will avoid calling the handlers ( which are used to parse the local
part ).
I agree the right solution is to add the dummy handler ( or a 'real' jar
handler ! ) in the compat package. It must at least parse the URL,
otherwise it'll brake reloading ( since getFile() is used to add the jar
location to the list of files that are checked for modifications ).
Costin
On Fri, 7 Sep 2001, James THOMAS wrote:
Thanks for the great info Costin.
Just an FYI, I did implement another solution, which was to implement a
Handler class for the jar protocol. Interestingly enough, it was
sufficient to only have a class that is responsible for the jar protocol.
The implementation of the class could be crap because it is never used.
The explanation behind this is implementation of the DependClassLoader:
Basic Algorithm of loadClassInternal:
1) If class is already loaded, return it.
2) obtain the class as a resource from parent (but will don't construct
the Class yet). If the resource is not found, then throw a
ClassNotFoundException. This is where we are failing today because the
jar protocol does not have a handler in JDK 1.1
3) load the class from parent2 and return it if found.
4) no create the class from the resource loaded in step 2
By having a handler for the jar protocol, we get a non-null URL in step
2, thus avoiding the ClassNotFoundException. And in my testing, parent2
was always able to load the class requested. Thus, the resource (i.e. URL)
obtained from step 2 was never used.
===
===
Thanks James, I'm very happy to see your contributions. ( and my
appologies for not testing with 1.1 often enough ).
jakarta-tomcat-3.3-dev-src\src\share\org\apache\tomcat\util\depend\DependClassLoader.java
==
The method loadClassInternal appears to be incorrect. When loading a
class, the code first retrieves the class as a resource from the parent
class loader. But, the return value from the getResource is not used
because the code then delegates the class loading to the parent2 class
loader (parent2.loadClass(name)). When running with JDK 1.1, the
getResource returns null because the jar protocol is not valid (the
exception message unknown protocol: jar is thrown from
SimpleClassLoader
where a java.net.URL is constructed). This causes the
loadClassInternal
method to throw a ClassNotFoundException prematurely because the class
can successfully be loaded by one of the the parent class loaders. Below
I
offer a solution but I think it would be best if someone with a more
in-depth understanding of the code can validate this solution.
The code is a bit tricky. 3.3 uses normal URLClassLoaders for loading, but
in order to support reloading we use an additional wrapper (
DependClassLoader ) that will collect dependencies ( since a servlet/jsp
can depend on multiple jars/classes ).
For DCL, parent is the webapp class loader. parent2 is the
applications class loader, parent of all webapp loaders.
The code tries to make DependClassLoader as non-intrusive as possible (
i.e. the behavior of using DCL should be as close as possible to 'normal'
).
If a class can be loaded by parent2 ( the common app loader ), then we
just delegate to it ( that's the normal delegation that would be used if
no DCL was present ). We don't delegate to parent because then all classes
loaded as result of resolving the current class would not be registered as
depends ( parent will do all the loading without any notification ).
If not, we'll use parent to get the bytes - then load them. The reason
Re: Tomcat 3.3 (JDK 1.1 compatibility fixes)
I'm using IBM's JDK 1.1.8
I feel almost certain that it does not have a jar protocol handler.
I tried your suggestion but I still get the exception:
java.net.MalformedURLException: unknown protocol: jar
at java.lang.Throwable.init(Throwable.java:74)
at java.lang.Exception.init(Exception.java:38)
at java.io.IOException.init(IOException.java:38)
at
java.net.MalformedURLException.init(MalformedURLException.java:38)
at java.net.URL.init(URL.java:201)
at java.net.URL.init(URL.java:222)
Looking at JDK 1.1.8 javadoc it seems that a URL Handler for the protocol
is created:
If this is the first URL object being created with the specified
protocol, a stream protocol handler object, an instance of class
URLStreamHandler, is created for that protocol:
James
==
==
Thanks again James.
I think I understand now.
First question - what VM are you using ? JDK1.1.8 ( Sun and IBM ) seem to
have handlers for jar protocol ( even if it's not standard AFAIK ). Long
time ago I tested with kaffe and it worked - but I'm not sure I tested
getResource().
The real problem is not in DependClassLoader, but SimpleClassLoader, where
getResource() is implemented. Even if we 'hack' DCL to not call
getResource(), I think it would be better, as you sugest, to add code to
support the jar protocol.
The problem is in SCL.getResource(), the code is:
// a jar:-URL *could* change even between minor releases, but
// didn't between JVM's 1.1.6 and 1.3beta. Tested on JVM's from
// IBM, Blackdown, Microsoft, Sun @ Windows and Sun @ Solaris
if( r.zipEntry != null ) {
try {
return new URL(jar:file: +
r.repository.getPath() + !/ +
name);
} catch(java.net.MalformedURLException badurl) {
One thing you can try ( and may work ) is to replace this with
new URL(jar, null, r.repository.getPath() + !/ + name );
This will avoid calling the handlers ( which are used to parse the local
part ).
I agree the right solution is to add the dummy handler ( or a 'real' jar
handler ! ) in the compat package. It must at least parse the URL,
otherwise it'll brake reloading ( since getFile() is used to add the jar
location to the list of files that are checked for modifications ).
Costin
On Fri, 7 Sep 2001, James THOMAS wrote:
Thanks for the great info Costin.
Just an FYI, I did implement another solution, which was to implement a
Handler class for the jar protocol. Interestingly enough, it was
sufficient to only have a class that is responsible for the jar
protocol.
The implementation of the class could be crap because it is never used.
The explanation behind this is implementation of the DependClassLoader:
Basic Algorithm of loadClassInternal:
1) If class is already loaded, return it.
2) obtain the class as a resource from parent (but will don't construct
the Class yet). If the resource is not found, then throw a
ClassNotFoundException. This is where we are failing today because the
jar protocol does not have a handler in JDK 1.1
3) load the class from parent2 and return it if found.
4) no create the class from the resource loaded in step 2
By having a handler for the jar protocol, we get a non-null URL in step
2, thus avoiding the ClassNotFoundException. And in my testing,
parent2
was always able to load the class requested. Thus, the resource (i.e.
URL)
obtained from step 2 was never used.
===
===
Thanks James, I'm very happy to see your contributions. ( and my
appologies for not testing with 1.1 often enough ).
jakarta-tomcat-3.3-dev-src\src\share\org\apache\tomcat\util\depend\DependClassLoader.java
==
The method loadClassInternal appears to be incorrect. When loading a
class, the code first retrieves the class as a resource from the
parent
class loader. But, the return value from the getResource is not used
because the code then delegates the class loading to the parent2
class
loader (parent2.loadClass(name)). When running with JDK 1.1, the
getResource returns null because the jar protocol is not valid (the
exception message unknown protocol: jar is thrown from
SimpleClassLoader
where a java.net.URL is constructed). This causes the
loadClassInternal
method to throw a ClassNotFoundException prematurely because the
class
can successfully be loaded by one of the the parent class loaders.
Below
I
offer a solution but I think it would be best if someone with a more
in-depth understanding of the code can validate this solution.
The code is a bit
Re: Tomcat 3.3 (JDK 1.1 compatibility fixes)
Thanks James, I'm very happy to see your contributions. ( and my
appologies for not testing with 1.1 often enough ).
jakarta-tomcat-3.3-dev-src\src\share\org\apache\tomcat\util\depend\DependClassLoader.java
==
The method loadClassInternal appears to be incorrect. When loading a
class, the code first retrieves the class as a resource from the parent
class loader. But, the return value from the getResource is not used
because the code then delegates the class loading to the parent2 class
loader (parent2.loadClass(name)). When running with JDK 1.1, the
getResource returns null because the jar protocol is not valid (the
exception message unknown protocol: jar is thrown from SimpleClassLoader
where a java.net.URL is constructed). This causes the loadClassInternal
method to throw a ClassNotFoundException prematurely because the class
can successfully be loaded by one of the the parent class loaders. Below I
offer a solution but I think it would be best if someone with a more
in-depth understanding of the code can validate this solution.
The code is a bit tricky. 3.3 uses normal URLClassLoaders for loading, but
in order to support reloading we use an additional wrapper (
DependClassLoader ) that will collect dependencies ( since a servlet/jsp
can depend on multiple jars/classes ).
For DCL, parent is the webapp class loader. parent2 is the
applications class loader, parent of all webapp loaders.
The code tries to make DependClassLoader as non-intrusive as possible (
i.e. the behavior of using DCL should be as close as possible to 'normal'
).
If a class can be loaded by parent2 ( the common app loader ), then we
just delegate to it ( that's the normal delegation that would be used if
no DCL was present ). We don't delegate to parent because then all classes
loaded as result of resolving the current class would not be registered as
depends ( parent will do all the loading without any notification ).
If not, we'll use parent to get the bytes - then load them. The reason we
have DependClassLoader12 is to support the security context - I couldn't
find any other way ( like via jdkcompat ) since we need to call a
protected method in super.
// check parent class
if( parent != null ) {
try {
c = parent.loadClass( name );
^^^ That will not brake part of reloading - parent will load all classes
that are requested by the current class, and we'll not be able to record
that...
I'll try to find another fix ( nice try ! :-).
Costin
RE: Tomcat 3.3 contextAdmin issues
On 20 Aug 2001 02:01:12 +0200, Paulo Gaspar wrote: Your explanation sure helps understanding what functionality is intended for each tag. I can take a look at that too. It is easier for me to understand the taglibs than the rest of Tomcat. =;o) Well, I hope understanding the rest of tomcat is not that difficult, but the goal of the tags was to hide tomcat implementation details ( or tomcat itself ). A context tag can have different implementations, maybe specific to other servlet containers - the admin interface will be the same, just a different taglib code will be used. BTW, nothing requires you to use the tags or jsp - but whatever you use, please keep the implementation behind an interface similar with the tags. ( i.e. similar name and behaviors ). In this case I am talking about the comments in the method org.apache.tomcat.core.ContextManager.shutdown() In this method's source code there are 2 blocks of cleanup code that were commented out. The fact that they were not just removed and the nature of a comment: remove the modules ( XXX do we need that ? ) before one of those blocks makes me wonder how sure it is that they are correct. The code that is commented out used to be part of the method, including the one with XXX comment ( and the answer is - we don't need to remove the modules ). The idea is quite simple - shutdown() is symetrical with init(). If you add any context manually ( for example EmbededTomcat.addContext() ), you should also remove it when you stop ( if you want to ). If a module is adding contexts - it should also remove them ( or leave them in and don't add them back ). That's probably where the bug is, I need to review ContextXmlReader and AutoWebApp to make sure they remove the contexts on shutdown. shutdown() followed by init() should bring you back to the same state as you were before ( if no configuration change happened ). Now, that's the theory - or what seems to be the 'correct' behavior for the core. 3.3 is mostly about making sure the core behaves in a well defined way - better modules will follow, and we can fix modules easily without all the headache of a major release. If you have any doubts about the ContextManager behavior - please speak now, we may still be able to fix it. Regarding the module removal - again, whoever adds modules should also remove them back, shutdown shouldn't mess with that ( since init doesn't either ). In future, some modules will be enhanced to deal 'nicely' with restarts, and I plan to add support module reloading ( via a module, of course :-). As I mentioned so many times, after 3.3 we shouldn't have to change anything in the core, so new modules can rely on some known and well defined behavior ( well defined doesn't mean perfect, but good enough :-). Specific questions, besides the above ContextManager.shutdown() issue: - Why is it possible to add 2 or more contexts with the same name and base path? It is a cleanup issue that this happens with the restart.jsp code, but shouldn't this kind of duplication also be prevented? Contexts should be identified by hostname and base path. If we don't check for that - it's a bug. BTW, the right way to fix the bug is to add the check - not in the core, but in a module ( that can do other checks during the addContext/contextInit phases ). Again, this can wait until after 3.3, I don't think it's a major issue. - To make a hot restart, it looks like modules should be restarted too. Is this correct? Modules should deal themself with the init/shutdown events, and restart. Most existing modules do not need to be reloaded - but that can be done too. I'm still investigating how to implement module restart, and hot module add/remove. I don't think this can be done in 3.3, but in a set of modules that can be released after 3.3 ( I have some code, but now I want to focus on 3.3 and few other important pieces ). - When using restart.jsp, previously removed contexts (using the admin pages) were not added back. Why? Bug probably :-) Again, the right behavior is that whoever adds something should take it back. - Where are existing contexts detected and loaded? Is it on a module? And if yes, then which? Contexts ( and modules ) are added in 2 ways: - in applications embedding tomcat, by the application via calls to EmbededTomcat or ContextManager. - in standalone tomcat, by various configuration modules. Right now the list is: ContextXmlReader AutoWebApp. The first will add modules declared in apps-XXX.xml and server.xml ( which shouldn't be used for contexts, that's only for backward compat ). The second deals with webapps-like dirs ( you can define additional dirs, very usefull for multiple virtual hosts ). Thats' where you should check what happens on shutdown. BTW, this review will help a lot - thank you very much. I think it's very important to make sure the behavior is right in the first place, we can fix the
RE: Tomcat 3.3 contextAdmin issues
Answer inline:
-Original Message-
From: Costin Manolache [mailto:[EMAIL PROTECTED]]
Sent: Saturday, August 18, 2001 8:29 PM
On 18 Aug 2001 19:56:33 +0200, Paulo Gaspar wrote:
...
The first two things that are really confusing are:
- the existence of 2 lines of very similar classes
(e.g.: TomcatAdmin and ContextAdmin) in the tadm
package at webapps\admin\WEB-INF\classes\tadm;
Well, TomcatAdmin is the first tag I wrote, and it did a lot of things.
Too many, actually, so I started to split it. ContextAdmin will focus on
context tasks, TomcatAdmin for generic tomcat.
Also, TomcatAdmin declares the ContextManager scripting variable, and
that's a problem to be fixed - you can have only one tadm:admin in a
page right now.
Yes, I was thinking the same about that variable. I had to go around that
to improvise a context restart (by using % { % and % } %).
Your explanation sure helps understanding what functionality is intended
for each tag. I can take a look at that too. It is easier for me to
understand the taglibs than the rest of Tomcat.
=;o)
- and the fact that restart.jsp does not work as
expected producing duplicate entries in the list
presented by contextList.jsp.
That's a bug. I'll take a look, I wrote restart.jsp mostly as a test -
to make sure all modules are cleaning up after themself ( i.e. you do
restart.jsp few times and check the thread count, memory use, etc - it
should stay constant ). If some contexts are not removed - that must be
fixed ( please add a bug so I'll remember ).
I will try (adding the bug).
Looking at org.apache.tomcat.core.ContextManager did
not help a lot since its comments are not very clear
either, as is the case of its shutdown() method where
comments make me doubt about how cleanup should be done.
Ok, what's not clear :-) ? As you know, I'm not very good at docs, but
if you ask specific questions I may be able to answer ( and fix the
comments along the way ).
No one seems to be very good at docs on Tomcat. =;o)
In this case I am talking about the comments in the method
org.apache.tomcat.core.ContextManager.shutdown()
In this method's source code there are 2 blocks of cleanup code that
were commented out. The fact that they were not just removed and the
nature of a comment:
remove the modules ( XXX do we need that ? )
before one of those blocks makes me wonder how sure it is that they
are correct.
This restart thing probably has some relation with the
work Costin is doing on EmbededTomcat - maybe the
information missing is the same.
It has some relation, in the sense EmbeddedTomcat must be able to
restart ( and it's using the same calls as restart.jsp ).
Yes, the cleanup issues are related.
Specific questions, besides the above ContextManager.shutdown()
issue:
- Why is it possible to add 2 or more contexts with the same name
and base path? It is a cleanup issue that this happens with the
restart.jsp code, but shouldn't this kind of duplication also
be prevented?
- To make a hot restart, it looks like modules should be restarted
too. Is this correct?
- When using restart.jsp, previously removed contexts (using the
admin pages) were not added back. Why?
- Where are existing contexts detected and loaded? Is it on a
module? And if yes, then which?
As you see from the above questions, I still ignore a lot.
Thanks a lot for your attention on this, Costin.
Have fun,
Paulo Gaspar
Re: Tomcat 3.3 contextAdmin issues
On 18 Aug 2001 19:56:33 +0200, Paulo Gaspar wrote: I have been trying to improve a bit on the admin application, especially on the contextAdmin bit, tweaking its web pages/JSPs in order to add functionality and ease of use. Great :-) I am especially interested on making it easier to restart individual applications, deploy or redeploy new applications and restart the whole container trough this web interface. The first two things that are really confusing are: - the existence of 2 lines of very similar classes (e.g.: TomcatAdmin and ContextAdmin) in the tadm package at webapps\admin\WEB-INF\classes\tadm; Well, TomcatAdmin is the first tag I wrote, and it did a lot of things. Too many, actually, so I started to split it. ContextAdmin will focus on context tasks, TomcatAdmin for generic tomcat. Also, TomcatAdmin declares the ContextManager scripting variable, and that's a problem to be fixed - you can have only one tadm:admin in a page right now. - and the fact that restart.jsp does not work as expected producing duplicate entries in the list presented by contextList.jsp. That's a bug. I'll take a look, I wrote restart.jsp mostly as a test - to make sure all modules are cleaning up after themself ( i.e. you do restart.jsp few times and check the thread count, memory use, etc - it should stay constant ). If some contexts are not removed - that must be fixed ( please add a bug so I'll remember ). Looking at org.apache.tomcat.core.ContextManager did not help a lot since its comments are not very clear either, as is the case of its shutdown() method where comments make me doubt about how cleanup should be done. Ok, what's not clear :-) ? As you know, I'm not very good at docs, but if you ask specific questions I may be able to answer ( and fix the comments allong the way ). This restart thing probably has some relation with the work Costin is doing on EmbededTomcat - maybe the information missing is the same. It has some relation, in the sense EmbeddedTomcat must be able to restart ( and it's using the same calls as restart.jsp ). Costin
Re: tomcat 3.3 proposals cleanup - next step ?
On Tue, 26 Jun 2001, GOMEZ Henri wrote: Larry does a cleanup on Tomcat 3.3 project and remove many dirs in proposal but I removed all the proposal subdir from my local CVS and got all the proposal subdir trees at the next checkout. In the Unix and CYGWIN versions of CVS (at least), you can do your updates like this: cvs update -d -P and you won't have these directories present on your disk -- although there will still be some time spent scanning the server-side versions. All it used not less than 1.5Mb. What about removing (rm) also the directories in CVS dir to avoid grabbing 1.5Mb of subdirs : Doing this would violate a basic premise of source code control systems -- that you can *always* go back to a previous version (with a specific tag, or as of a specific date). It may be that a proposals directory doesn't really qualify for being concerned about this (since the code wasn't ever included in a production release), but it's appropriate to think very seriously before doing such a thing. Henri Gomez ___[_] Craig
RE: Tomcat 3.3 or 4.0 under Netbeans 3.2 anyone?
ok, nevermind, I already found some help for this: http://www.netbeans.org/www-nbusers/msg06837.html Neeme -Original Message- From: Neeme Praks [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 23, 2001 3:13 PM To: [EMAIL PROTECTED] Subject: Tomcat 3.3 or 4.0 under Netbeans 3.2 anyone? Is there anyone out there who has gotten Tomcat 3.3 or 4.0 working under Netbeans 3.2 IDE? It doesn't have to be very integrated with the IDE, I just want to debug my servlets, no JSP or anything... I tried, but due to the new (pretty advanced) classloading scheme, I'm not sure how to accomplish this... Can someone give some hints? Petr? Neeme
Re: Tomcat 3.3 or 4.0 under Netbeans 3.2 anyone?
Neeme, I didn't try myself, but the basic scheme for debugging servlets is the following: 1) Modify the Tomcat startup script so JVM runs in the debugging mode - we use something like the following: C:\jdk1.3.1\jre\..\bin\java -classic -Xdebug -Xnoagent -Xrunjdwp:transport=d t_socket,address=pjiricka-ws:1180,suspend=y -Djava.compiler=NONE "-Xbootclasspath:C:\jdk1.3.1\jre\..\lib\tools.jar;C:\jdk1.3.1\jre\lib\rt.jar ;C:\jdk1.3.1\jre\lib\i18n.jar;C:\jdk1.3.1\jre\lib\sunrsasign.jar;C:\jdk1.3.1 \jre\classes;" ..etc, but this may differ based on your platform, JDK version etc. This involves a bit of magic, so you may have to play with it a bit. 2) Set breakpoints in the IDE where you want them 3) In NetBeans, choose Debug - Attach, and in the "Attach" dialog choose Default Debugger (JPDA), SocketAttach, and port=1180 (the number you gave to the VM in the Xrunjdwp parameter. 4) Invoke requests from your web browser, the debugger should stop on the breakpoint. Of course there are many possible combinations, like you can use the JDK 1.1 debugging architecture (which is not as stable as JPDA, though), you can use shared memory access, etc. There is a good overview of possible options at http://java.sun.com/products/jpda/doc/conninv.html . I hope this helps. Petr - Original Message - From: "Neeme Praks" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 23, 2001 2:12 PM Subject: Tomcat 3.3 or 4.0 under Netbeans 3.2 anyone? Is there anyone out there who has gotten Tomcat 3.3 or 4.0 working under Netbeans 3.2 IDE? It doesn't have to be very integrated with the IDE, I just want to debug my servlets, no JSP or anything... I tried, but due to the new (pretty advanced) classloading scheme, I'm not sure how to accomplish this... Can someone give some hints? Petr? Neeme
RE: Tomcat 3.3 Milestone 3 status
Larry, I just tested this with 3.2.2b5 using Apache, mod_jk and AJP12 and the .jsp%20 problem does indeed exist. When running stand-alone the request returns a 404 error, but with mod_jk the JSP source is returned. If you could port your fix into tomcat_32 that would be great. Let me know what you find. -Original Message- From: Larry Isaacs [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 16, 2001 2:22 PM To: '[EMAIL PROTECTED]' Subject: Tomcat 3.3 Milestone 3 status Hi All, I'm in the process of preparing Tomcat 3.3 Milestone 3. Please consider the MAIN branch of jakarta-tomcat frozen for the time being. The current hold up is that mod_jk will serve JSP source for URL's that end with .jsp%20. As soon as I fix this, the Milestone 3 release will soon follow. I'll announce when Tomcat 3.3 development is unfrozen. Cheers, Larry P.S. Marc, a quick scan of mod_jk code didn't reveal differences that would suggest that mod_jk in Tomat 3.2.2 doesn't also have this problem. If there is already a fix, please let me know. Or, if not, let me know if you want me to port my fix. __ Larry Isaacs [EMAIL PROTECTED] SAS Institute Inc.
RE: Tomcat 3.3 Milestone 2 status
Hi, The jakarta-tomcat project has been tagged in CVS, so commits may resume. If you need Tomcat 3.3 Milestone 2 source, be sure to checkout with the tag tomcat_33_m2. I have built the Windows connectors for Milestone 2. Those who wish to contribute additional connectors may e-mail me directly. Cheers, Larry -Original Message- From: Larry Isaacs [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 14, 2001 9:36 AM To: '[EMAIL PROTECTED]' Subject: Tomcat 3.3 Milestone 2 status Hi, We are now in the process of constructing Tomcat 3.3 Milestone 2. Until further notice, please consider the jakarata-tomcat MAIN branch frozen. Thanks, Larry __ Larry Isaacs [EMAIL PROTECTED] SAS Institute Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat 3.3 Milestone 1 Status
Hi Larry, What about doing that after weekend ? Let's say is superstition, but so far Monday has been a good day for milestones. Though not completely frozen, only simple (i.e. safe) bug fixes should be made at this point. If there is something bigger that you think should be in TC3.3m1, please contact me first before committing. All code changes for ant syntax in server.xml are done, but the old syntax is still used. I checked in server1.xml with the new one, I think we should have it enabled by default. There are minor changes needed to support "profiles", I'm very confident they'll have minimal impact. It will be implemented by a separate module - basically no change in the current code, but I would like the config file to be written using the new style. -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Tomcat 3.3 Release Plan Voting Results
Hi Larry, I did not vote since I have no right to do it, but I would like to help. I am starting to use TC 3.x HEAD and getting familiar with its internals. If there are some fixes that do not demand for a wide knowledge of Tomcat (as if they just involve a couple of modules) I am willing to do that kind of work. I will also review as much code as I can (which is something that helps learning more about TC). If there are preferences about which modules should benefit more from reviews, please say so. Thanks, Paulo Gaspar -Original Message- From: Larry Isaacs [mailto:[EMAIL PROTECTED]] Sent: Monday, February 05, 2001 15:37 Hi All, My tally of the Tomcat 3.3 Release Plan shows the release plan being approved with the following vote totals. +18 +08 01 -0none -1none Thanks for the show of support. I'll be e-mailing those who voluteered earlier to work in specific areas. Together, I hope we can bring Tomcat 3.3 to a state where the vote to release Tomcat 3.3, which should occur in a couple of months, will be as positive as this one. Cheers, Larry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat 3.3
Hello, I've been reading both this and the dev list for about a month and asking/answering the more well put user questions (meaning I don't do to well on the ones that just say "Tomcat 3.x.x doesn't work on linux) and nothing else). I'd like to contribute to a tomcat, but since there are three of them I'm not horribly sure where to start. I know 4.0 is a rearchitecture and 3.2.x is basically the old architecture, and that 3.3 is probably less supported than 4.0 (in that sun will probably package 4.0 in the next major j2ee). But, that being the case (and I know I'm touching on a sore spot) what will be the lifespan of 3.3. There've been a few messages on this subject but all of them were a bit too hotheaded for me to gain the information I desired from them. I know this is somewhat of a partisan issue and the lines have been drawn, but just delving in I'd guess 3.2.x would probably not be the best place to start (even though I'm using it) as being unfamiliar with the code and it being supposidly "the worst" code of the 3, I'd probably learn it in time to see it go out of fashion (though I'm guessing, without a real idea what the planned lifespan is). I'm guessing 4.0 might be a bit hard to get into as I picture the major decisions being made in a sun boardroom somewhere in cupertino where i'd not have the time to make it to and probably wouldn't be invited anyhow... But is 3.3 going to have a long enough lifespan to make it worth my while? Is help needed there? I probably prefer to start out with bug fixes as its easier to get into "if you do this than this breaks". So some direction (preferrably without the partisan slant) would be very helpful. Thanks, Andy __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
Re: Tomcat 3.3
Andy wrote: But, that being the case (and I know I'm touching on a sore spot) what will be the lifespan of 3.3. Since a proposal to publish a "Tomcat 3.3" has never been formally presented and voted on, the only logically correct answer is "I don't know." Depending on the results of a vote, it could be anything from "it will never be released (as Tomcat -- the code is free for anyone to do what they want with)" to "live long and prosper". Given the current emotionally charged climate, I would not suggest that anyone propose a vote on 3.3 at the moment :-). [snip] I'm guessing 4.0 might be a bit hard to get into as I picture the major decisions being made in a sun boardroom somewhere in cupertino where i'd not have the time to make it to and probably wouldn't be invited anyhow... I'm guessing (well, not really -- it's pretty obvious :-) you haven't studied your history very well. For an interesting bit of background, you might go check out the CVS repository for Apache JServ at http://java.apache.org and select the branch labelled "JSERV1_1DEV". (Yes, it started before there was a 1.1 release of Apache JServ). Note the dates on those files (early to mid 1999, before the Sun contribution of Tomcat was announced). Go look at the source, and you will see the recognizable architecture that is Catalina (the servlet container part of Tomcat 4.0) today. For the record, Sun hired me in March, 2000, so that I could work on Tomcat full time instead of it just being a hobby (as it was when the original code was written). :-) Andy Craig McClanahan
Re: Tomcat 3.3
"Craig R. McClanahan" wrote: Andy wrote: But, that being the case (and I know I'm touching on a sore spot) what will be the lifespan of 3.3. Since a proposal to publish a "Tomcat 3.3" has never been formally presented and voted on, the only logically correct answer is "I don't know." Depending on the results of a vote, it could be anything from "it will never be released (as Tomcat -- the code is free for anyone to do what they want with)" to "live long and prosper". Kinda hard to go on. Given the current emotionally charged climate, I would not suggest that anyone propose a vote on 3.3 at the moment :-). I'd say you might have just invited it. [snip] I'm guessing 4.0 might be a bit hard to get into as I picture the major decisions being made in a sun boardroom somewhere in cupertino where i'd not have the time to make it to and probably wouldn't be invited anyhow... I'm guessing (well, not really -- it's pretty obvious :-) you haven't studied your history very well. Other than reading the site and newsgroups without actually being here x years ago, its not as if there is a "Complete history of tomcat". And honestly I probably would find it a bit dry. (see Shakespeare's "Loves Labours Lost" for more entertaining reading). I'm just trying to find a starting point. For an interesting bit of background, you might go check out the CVS repository for Apache JServ at http://java.apache.org and select the branch labelled "JSERV1_1DEV". (Yes, it started before there was a 1.1 release of Apache JServ). Note the dates on those files (early to mid 1999, before the Sun contribution of Tomcat was announced). Go look at the source, and you will see the recognizable architecture that is Catalina (the servlet container part of Tomcat 4.0) today. Cool. For the record, Sun hired me in March, 2000, so that I could work on Tomcat full time instead of it just being a hobby (as it was when the original code was written). :-) My comments were not directed at you, I appologize if I offended anyone as was not my intention. My desire is to get involved in a piece of open source software I actually use (therefore can have the time to study and contribute to in my free time without getting a divorce G), working for a money has been taking the fun out of computers so I wanted to work for something else. Again, no offense was intended, I was just summing up the best conclusions I could come up with from reading the newsgroups. Maybe the best thing would be if one of the commiters gave me a piece of their bug they don't feel like finding. From your comments I have a question: Has 4.0 been voted on ? ( if this is politically charged please read this in the context it is intended which is NOT controversy, I'm a programmer not a political type)... If it will indeed be released and maintained and contributions are welcome than maybe that's a good starting point. Thanks, Andy _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: Tomcat 3.3
Andy wrote: Maybe the best thing would be if one of the commiters gave me a piece of their bug they don't feel like finding. The interim bug reporting system we are using http://znutar.cortexity.com has tons of outstanding bugs. I would not bother with the Tomcat 3.1 bugs -- anyone who is using 3.1 is strongly urged to upgrade to 3.2. The easiest way to find them is go to the Viewer, then "Display all bug reports in a specific project", then select "Tomcat". (The 4.0 bugs are supposed to be under "Catalina" and "Jasper", but not everyone does it that way, so you have to check the "Tomcat" list as well.) Everyone using 3.2 or 3.2.1 in production would be incredibly appreciative if bugs on it were found and fixed, and a 3.2.2 release was prepared. Submit a few bug fixes, and you'll probably find yourself nominated as a committer if you're interested :-). As for future versions, it should be obvious what I spend my time on -- everyone of course is free to do what they want in that respect. From your comments I have a question: Has 4.0 been voted on ? ( if this is politically charged please read this in the context it is intended which is NOT controversy, I'm a programmer not a political type)... If it will indeed be released and maintained and contributions are welcome than maybe that's a good starting point. Yes, in September 2000 the vote to use Catalina as the basis for Tomcat 4.0 took place on the TOMCAT-DEV mailing list. The votes would be in the mailing list archives (and yes, the web site can do a better job of pointing people to where various archives of TOMCAT-DEV can be found -- updating the web site is yet another useful way to contribute). Welcome! Thanks, Andy Craig _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: Tomcat 3.3
"Craig R. McClanahan" wrote: For the record, Sun hired me in March, 2000, so that I could work on Tomcat full time instead of it just being a hobby (as it was when the original code was written). :-) And thank you for not accepting my offer at that time, otherwise you would be working on Business Processes right now, and not on Catalina... Pier -- Pier Fumagalli [EMAIL PROTECTED] http://www.betaversion.org/~pier
Re: Tomcat 3.3
Yeah i saw that. I'm planning a few updates. Jon Stevens wrote: on 12/21/2000 1:13 PM, "Craig R. McClanahan" [EMAIL PROTECTED] wrote: updating the web site is yet another useful way to contribute). It is even documented on how to do that! http://jakarta.apache.org/site/jakarta-site2.html :-) -jon -- Honk if you love peace and quiet. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
Yes, We saw many reference of code to be fixed on 3.3. Now that some want to kill 3.3 and directly play with 4.0, the risk of having a 3.x branch (the current branch) falling in 'unsupported software land' is VERY HIGH. This is open source - it's supported as long as some developers are supporting it :-) As long as people are using it, the source code and license will keep it alive. Sorry but for now the only existing and used branch is 3.x (3.1 and 3.2b) We need a URGENTLY a 3.2 release (with a bug lists) and start the 3.3 beta. +1 As soon as 3.2 is released I'll make a proposal to freeze 3.3 in 2-4 weeks. Right now 3.3 is almost ready for feature freeze, but we'll need to merge all the small bug fixes that went into 3.2. ( ready for feature freeze doesn't mean is ready for release !- it has old and new bugs, but the major changes are almost done ). As I said earlier, I don't think we'll need a 3.4 or more changes in the core very soon - unless somone finds a use case that can't be implemented with the current architecture or a big performance improvement that requires a core change. After 3.3 we can have minor ( dot.dot ) releases or just provide updated interceptors. ( that doesn't means 3.x is ended, just that it'll be stable enough as a framework, and future development can be done without braking backward compatibility and in separate modules ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Liam Magee [EMAIL PROTECTED] wrote: I have been a long-time silent listener on this list, and use Tomcat 3.1 in a production environment. I have been greatly appreciative of the hard work gone into the software to date, and respect that its development is on a volunteer basis. But I fully concur with the sentiments of this posting - for the past couple of months it's been completely unclear as what the development path and release schedule for Tomcat looks like (3.2?, 3.3?, 4.0?). I would like to continue to use Tomcat, and eventually have time to get more involved in its development, but the lack of any obvious plan and schedule leaves companies like ours considering whether we need to fall back to commercial offerings to get any kind of reliability or accountability for the direction of releases. Again, I respect that the basis of this project is volunteer-driven, but it is possible to get a balance between the democratic impulses of OSS and a more rigorous project management approach to 'deliverables'? Let me wear my "foundation member" hat for a while, try to make a point of the current situation, and explain something that is obvious for long-time developers, but might not be so clear for newcomers. First of all let's clear up a long time issue (I reply to webmaster@jakarta too, and this question keeps popping up) What is Tomcat? Tomcat, the Jakarta Apache flagship product, is (as the web site states) the Reference Implementation for the Java Servlet and JavaServer Pages Technologies. Let's try to explain this a little bit: Tomcat is NOT a servlet engine and it is NOT a JSP engine/compiler; Tomcat is the union of those two separate technologies. Some confusion have arised in the past because in the 3.x tree Tomcat is the name of BOTH the servlet engine AND of the full distribution. But, recognized this problem, in the new 4.x tree we changed things to make better understand this distiction: "Catalina" is the servlet engine, "Jasper" is the JSP engine/compiler and "Tomcat" is the union of those two. What does this mean? This means that, at the end, you will be able to download Catalina (if you need only servlets), Jasper (if you want to use JSPs on ANY servlet engine, even on Allaire's JRun hopefully), or Tomcat (if you want to use the full distribution from Apache). Why all this confusion? Why do we need Tomcat? Can't we just have "Catalina" and "Jasper"? No, we can't... Because Tomcat (the full product) is the reference implementation of the Java Community Process' JSR-53, so, one JSR, one specification, one name, one distribution... (Ok, I have to save this one for all the webmaster@jakarta emails). Now, to explain a little bit how we are organized, let me say that we're far from the time when we were a bunch of kids playing at Java.Apache.ORG with JServ. Now we are part of the Apache Software Foundation, and because of that, we have to obey to some rules. Most of our self-imposed regulations were derived by the invaluable experience gathered by the HTTPD project (the web-server) and that was absorbed by all other branches of the foundation by osmosis. We have a voting process, a vetoing process, a list of people who have the right, and the due (I would like to underline this!) to vote on issues. This all is clearly described in our "Guidelines" page, please READ it, because that's the LAW in this community. Once an issue is found (a new release, a new codebase, anything that needs a general agreement), all the committers (people with access to the CVS) are asked for a vote. And when a decision is took, it's a responsibility of those voting committers to maintain what was promised. (Yes, if you're a committer, you have responsibilities in front of the community... Again, we're far from the old JServ days). Now, to sum up what happened in the last few months: Some of us (in particular Craig, me, Jon, Remy and others) weren't feeling comfortable with the Tomcat 3.x (Servlet Engine) codebase. Craig, the main author of what would have become JServ 2.0, asked the permission to create a new propositive servlet engine, we voted, and the "Catalina" proposal was created. When Servlet 2.3 and JSP 1.2 came along, this community was asked to vote again, on what codebase would have been used for this new reference implementation: we had to choose between Tomcat 3.x (Servlet Engine) and Catalina, and we decided to adopt Catalina as our next-generation servlet engine. In those last few days, I've seen emails going around with a "Tomcat 3.3" label stamped upon them, and that's when I started to wonder, and get confused. This community didn't vote for a Tomcat 3.3 release, nor we were asked what we were thinking about such a thing. Puzzled, I started asking around, and, aparently, what was clear in the past (Tomcat 3.2 release and then Tomcat 4.0) was all screwed up. For what concerns me, Tomcat 3.3 doesn't exist as an Apache Project. It was not voted upon, and it is in direct
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Luke Holden [EMAIL PROTECTED] wrote: What is the status of the Tomcat 4.0 web connector for apache (if any)? ARRGGH :) :) :) :) You know how to make me suffer... A beta will be available soon Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
"Pier P. Fumagalli" wrote: What is the status of the Tomcat 4.0 web connector for apache (if any)? ARRGGH :) :) :) :) You know how to make me suffer... A beta will be available soon hahahaha :) Well is there any way I can help? Although slightly new to java Ive been programming for a number of years. (I mainly program in c/c++ and php).. however I have recently cought onto the java language and I really enjoy it. I would love to help in any way I can :) -- Luke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
"Pier P. Fumagalli" wrote: So, I'm proposing this plan, and please vote on 2 and 4 (1 and 3 were already voted upon with a bunch of +1s)... 1) Release Tomcat 3.2 final (soon, please!) +1 2) Create a new proposal tree alongside with Catalina (new name to avoid confusion, please) +0 3) Release Tomcat 4.0 (with Catalina, as we all decided) +1 4) Decide wether Tomcat 5.0 will be Catalina based or "whatever" new proposal comes along. -1, way too early to consider this Get the Tomcat 4.0 Apache mod_warp connector committed. +1, ;-) -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
For what concerns me, Tomcat 3.3 doesn't exist as an Apache Project. It was not voted upon, and it is in direct contrast with what this community decided.rg I'm probably wrong, but I don't remember a vote that said Tomcat 3.2 was a new development over Tomcat 3.1. I thought it was clear that Tomcat 3.1 was an "unfinished" work and Tomcat 3.2 was necessary step down the road to finishing Tomcat's mission to provide an RI for the servlet 2.2/JSP 1.1 specs. In my opinion, Tomcat 3.2 doesn't finish the job. It has enough bugs and out of spec issues that it can't claim to be a "finished" RI. rantAnd it certainly wasn't left in a releasable state when work on it was for the most part abandoned by most everybody back in early summer./rant:-) So for the near term, I plan to put my efforts to "finishing" the Servlet 2.2/JSP 1.1 RI. At this point, my preference is to put that effort into Tomcat 3.3 as opposed to continuing to fix Tomcat 3.2. Though, if there is to be only a Tomcat 3.2 release and no Tomcat 3.3, I would prefer to not release the current Tomcat 3.2 and treat the MAIN branch as Tomcat 3.2.;-) I think Jakarta should provide a "quality" RI for the Servlet 2.2/JSP 1.1 specs, and in the future a "quality" RI for the Servlet 2.3/JSP 1.2 specs. IMHO, to release what we have now as the RI for 2.2/1.1 and say this is as good as the RI gets, would reflect badly on Jakarta. I admit to being selfish in this opinion. It is SAS Institute's intention to use Tomcat with our Java IDE. SAS has enough customers that do not jump on cutting edge technology, that 2.2/1.1 will be in use for a long while. We have a need for a solid Tomcat 3.x implementation, both as the RI and as a "well behaved" web server. This is where I will put my Tomcat 3.x efforts before moving on to Tomcat 4.0. Others are welcome to put their effort where it most interests them. Cheers, Larry Isaacs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
Sorry again, but this time I have to vote -1 on a "new" Tomcat 3.3, expecially before 3.2 final is out of the door. The NEXT major release is going to be Tomcat 4.0, based on Catalina, as we all agreed on months ago. The impression I got from reading the dev list was that 4.x was where everyone was going to be focussing, one 3.x was in a rockin' good state. Isn't that what happened to JServ? I thought the JServ page said something like, "JServ is only bug fixes from now on - go get Tomcat" ? I can't find where I read that now, so maybe I didn't, but I sure thought I did ;) Also, whatever the result of this discussion, we should most definitely have Pier's stuff on the main page (jakarta home and Tomcat home). From an, "I've never seen Tomcat before" being faced with two downloads, which one would you grab, seeing 3.1, 3.2b6 and 4.0M4 available? Maybe 3.2b6 if you're familiar with the software development process. It can confuse people who want to contribute as well. Who is the webmaster for jakarta? The project is very much alive and kicking, but there hasn't been a news update since July! I wouldn't say there there's no news considering the PHP home page ducking =) has updates when new betas are released. Maybe the main page should be a combined news/description page like the Java-Apache home. The list of products on the right with a description and release number? That's hella cool! - r - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
"I've never seen Tomcat before" being faced with two downloads, which one would you grab, seeing 3.1, 3.2b6 and 4.0M4 available? "being faced with two downloads, which of these three would you grab?" I think next time I won't get up at 6 am =) I think Jakarta should provide a "quality" RI for the Servlet 2.2/JSP 1.1 specs, and in the future a "quality" RI for the Servlet 2.3/JSP 1.2 specs. IMHO, to release what we have now as the RI for 2.2/1.1 and say this is as good as the RI gets, would reflect badly on Jakarta. FWIW I'm in total agreement here. I think the major functionality that was planned should be implemented, all the known killer bugs fixed up, etc. As a long-time (since early summer =) advocate of Tomcat, I would have a tough time explaining to people, "Well, 3.x is sort of this unfinished thing that they weren't happy with, so they started 4.x". To me, that DOES give the impression that the Tomcat project is indeed what Pier said exactly it is NOT: kids playing around in the org tree. - r - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Sorry Pier, but I don't think I'm doing anything wrong. I worked ( pretty hard ) on the last year or so on tomcat. I worked ( pretty hard ) convincing other people to contribute. Tomcat 3.1 is better that tomcat 3.0 ( or the old JWSDK ). Tomcat 3.2 ( as it was few months ago ) is better than tomcat3.1. It's not perfect - but it's better. There are fundamental problems ( that are present in other containers as well, even worse !), and 3.3 is going to fix them. I don't care how it'll be called, or where it'll stay ( an Apache Fundation member asked me to go to SourceForge and stop using the name "tomcat" - and Pier is asking me to make it a "revolution" and change the name to something else, as Tomcat is no longer correct ). The fundamental problems are: - can't support charset detection ( i.e. the encoding of the URI ) - there is a limit on performance because of excessive use of Strings - the code still need improvements in the modular structure. I have no idea why tomcat 3.2 hasn't been released - it's not my decision. As far as I'm concerned 3.2 is over ( for me ) - it's a step forward, but (as 3.1 ) it isn't perfect. I don't know any "critical" bug in 3.2 that wasn't in 3.1 also. Regarding the "confusion" of using "tomcat" ( i.e. 2 different codebases with the same name ) - well, I don't quite understand how it is my fault, but I'm going to work on the current ( "evolutionary" ) codebase, whatever you decide to call it. If mighty Apache Members or PMC decide to ban this project, or to change it's name - so be it. You can also revoke my account on locus - feel free to do it, it seems my presence there is less and less wanted. As long as my account still works ( and I'm still a commiter ), I'll continue to work as before - if the code I commit is buggy, please -1 it. I don't think I need a vote to add new features to tomcat 3.3 ( that are present in catalina ) - after all none of that was "proposed" or "voted" on the other codebase. Regarding the implementation of Servlet2.3 and JSP1.2 - I'm curious to see how will you "spin" this, but I think it's important to support the latest specs, and tomcat3 was designed with "facades" from beginning - ask Duncan why. To conclude ( I hope my last mail on this topic ) - I think tomcat3 is very good container, has a very good desing, and I don't think Apache "politics" and Apache hierarchies can stop good code for beeing developed. Costin P.S. I am not allowed to say anything about tomcat 4.0 or catalina, but I do hope that open source magic will work and people will compare the 2 architectures and decide what works better. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
time explaining to people, "Well, 3.x is sort of this unfinished thing that they weren't happy with, so they started 4.x". To me, that DOES give the 3.x and 4.x are 2 different servlet containers, with very different design. The only confusing thing is the fact that the same name is used for both, and the number looks like 4 is a continuation of 3. Which one is better should be based on code reading and real-world testing, not on the number that is stick on it. ( BTW, the feature set is very different, the core design is different and of course the performance is different too ) Again, I don't remember when Apache decided to throw away a particular design and codebase and the reasons behind it, but if Members decide so I don't think I can do too much about it. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
So what are our goals, anyhow ? I think we should concentrate on the following goals (in this order): 1) Provide a quality RI of Servlet 2.2/JSP 1.1. This is something that Tomcat 3.0 claimed to be, but until now we are still not quite sure ! 2) Provide a production quality implementation of Servlet 2.2/JSP 1.1, so the users don't have to ask "JServ ot Tomcat ?". 3) Provide support for future versions of the specifications, as both RI and production quality environment. Now, how do individual versions of Tomcat meet these goals ? Tomcat 3.1 meets neither, IMHO. Tomcat 3.2 does not meet 3), and it meets 1) much better than 3.1, enen though not perfectly. Are we happy with this ? Can we release 3.2 as it is now, or do we want to be 100% sure that we have 1) or even 2) ? Tomcat 4.x meets all, but it's not going to happen for a while. From this I think that clearly there is need for further development in the 3.x codebase, until we fully meet 1) and 2). Namely, we should release 3.2 ASAP. I consider it a big mistake that we (including myself) stopped development of 3.2 and didn't finish it yet. And I wouldn't want us to make the same mistake for 3.3: we don't necessarily need more features and new specification support in 3.3, particularly if that's going to delay the delivery of goal 2) (which should also happen ASAP). So 3.3 makes sense, but without support for the new specs, webdav etc. If we never finish what we started, then (as Rob said) we are a bunch of kids playing around in the org tree. My 2 Kc. Petr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
I'd like to speak up about this briefly. Catalina/Tomcat-4.0 may be the future which is fine, but Tomcat is now being used in production settings. We've been testing the 3.2b* releases and the performance is better than 3.1 which is important for us. The performance of 3.3 is supposed to be better still. Catalina may have the perfect design, but I can't say anything about that because I haven't gotten time to look at the code. From previous emails though, it sounds like the supporting code such as Apache httpd connectors may not be ready yet, let alone tested. Mod_jk wasn't perfect at the last time that I tested it, but it was functional. What am I saying? Tomcat 3.x may not be perfect yet, but it has the supporting software in place and working. Catalina may have the perfect embedded http server, but that is of no interest to us. We need the speed and flexibility of the Apache httpd. What I'm asking is will Catalina be ready for production usage any time soon? Has it been tuned for speed yet? As for 3.3, I see it as a finish of what 3.2 started. We don't need Servlet 2.3 yet, so that isn't important to us. What we need is stability and performance. Once 3.2 is in production use, people will find bugs and problems. Thats the nature of software. I think that should be the real place of 3.3. Take what has been done as far as performance, and the fixes for bugs and spec compliance issues from 3.2 and put them in 3.3 and release that. I think that perhaps the choice between the 3.x architecture and the Catalina proposal may have been a little premature. Catalina doesn't have the supporting features yet that the 3.x series has. We can't do a head-to-head comparison between the two because Catalina doesn't have the connectors in place yet. I would like to thank Costin and everybody involved in the 3.x series. They took a non-optimal code base and turned it into something suitable for production use. They got it up and running soon enough that it has been able to get traction in the industry and let us develop applications based off the newer specifications. They made the way for Tomcat 4.0, whatever code that may be. I don't think that code that works now should be thrown away until the code that is intended to replace it is ready to replace it. Paul Frieden On Sat, 4 Nov 2000 [EMAIL PROTECTED] wrote: time explaining to people, "Well, 3.x is sort of this unfinished thing that they weren't happy with, so they started 4.x". To me, that DOES give the 3.x and 4.x are 2 different servlet containers, with very different design. The only confusing thing is the fact that the same name is used for both, and the number looks like 4 is a continuation of 3. Which one is better should be based on code reading and real-world testing, not on the number that is stick on it. ( BTW, the feature set is very different, the core design is different and of course the performance is different too ) Again, I don't remember when Apache decided to throw away a particular design and codebase and the reasons behind it, but if Members decide so I don't think I can do too much about it. Costin - 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: Tomcat 3.3 / 4.0 confusion, rant and plan...
Everyone, I see no reason why Tomcat 3.x and 4.x have to be mutually exclusive. As far as I can tell, Tomcat 3.x is Servlet 2.2, and Tomcat 4.x is Servlet 2.3. It's as simple as that. Yes, the vote did happen. You now have Tomcat 4.x, and that is what I am using, and it is awesome! Craig, you rock! But, if there are spec compliance issues WRT Tomcat 3 and Servlet 2.2, then I believe development on the 3.x tree MUST continue, until Tomcat 3.x truly IS the RI of Servlet 2.2. Anything else would not make sense. The numbering (3.2, 3.3) does not matter. If you look at the httpd part of the ASF, they have been working on 1.3.x, as well as 2.x. What they did is they chose to only maintain the 1.3.x tree if Apache was not compliant with something in the HTTP spec itself, or bug fixes. They voted as a group to do any and all new feature development in the 2.x tree, and that is what they are doing. Since the 2.x tree creation, they have released 1.3.13, 1.3.14, and they are working on 1.3.15. Development has stopped, but bug fixing continues. 90% of the httpd work that goes on is in the 2.x tree, but the 1.3.x tree is alive, and will be for quite awhile. AFAIK, you guys voted to make Catalina the engine of choice for Tomcat in its Servlet 2.3 implementation, and you are doing that. I would say that the majority of development should eventually be on Catalina, but if Tomcat 3.x has spec issues, those should be fixed, unless you have also voted that Catalina is the RI for Servlet 2.2 as well. FWIW, the httpd people are EXTREMELY against any new features in the 1.3.x tree, but they do not stop new releases for bug fixes or spec-compliance issues. I think that should be the same type of thing here. Just my non-voting $.02. Scott Sanders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
On Fri, 3 Nov 2000, Pier P. Fumagalli wrote: Sorry for starting what it might end up as a long flamewar, but reading almost 500 emails on the list I ended up a little confused... Also, in a bunch of side discussions, but related always to the same topic, I feel there's something wrong going around here... Question: WHAT THE HACK IS TOMCAT 3.3 ??? I'm not disagreeing with you Pier, but I will say I believe that there are 2 possible ways to interpret the current situation, and I do not think I'm the only one who thinks this. 1) The fact that there are smart software developers out there contributing to Tomcat 3.x codebase and not necessarily contributing to the 4.0 codebase is a failure of the Jakarta Apache community to obtain sufficient buy-in from those people. The division of resources in this situation is what should be avoided at all cost, because this is the one major limitation OSS has: division of finite resources within a community because of forking. I would assume one of ASF goals is to prevent this. 2) Or alternatively, anything beyond Tomcat 3.1 refects that Tomcat 3.1 is a "rolling beta", which means the "code-train" is in such bad shape that the developers are throwing track in front of it as it moves forward. Not a good thing. Or maybe we have a combination between the two. At any rate, ASF should rule clearly whether to let the code-train of 3.x roll off the track, whether to let it continue to roll on track but away from it's auspices, or to support the two code bases as is. By doing nothing ASF implicitly supports the latter, which is counterintuive to ASF's entire raison d'etre. my $0.02 -Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
"Pier P. Fumagalli" wrote: Sorry for starting what it might end up as a long flamewar, but reading almost 500 emails on the list I ended up a little confused... Also, in a bunch of side discussions, but related always to the same topic, I feel there's something wrong going around here... Thanks Pier for bringing this issue to a vote. Based on the other replies to this mail, it seems to me like the majority wants Tomcat 3.x to be the RI for Servlet 2.2/JSP 1.1, with production quality of course, and Tomcat 4.x the RI for Servlet 2.3/JSP 1.2. That's what makes most sense to me. The devil may be in the details, but I hope we can make it so. [...] So, I'm proposing this plan, and please vote on 2 and 4 (1 and 3 were already voted upon with a bunch of +1s)... 1) Release Tomcat 3.2 final (soon, please!) +1000. Sam promised a release candidate a couple of weeks back, but it didn't happen (I'm sure for a good reason). If Sam doesn't have the time to do this now, maybe someone else who's familiar with the release procedures can step up to the task? When the release candidate is available, we should make sure it's tested quickly (I promise to do so with a number of JSP applications I have handy). Only serious regression bugs should be allowed to force another candidate cycle. For the future, I suggest we document the release procedures and put them in CVS so it's easier for someone to help out with this if the appointed release manager can't do it for any reason. 2) Create a new proposal tree alongside with Catalina (new name to avoid confusion, please) -1, two code bases is more than enough ;-) If we can agree that Tomcat 3.x is the RI for Servlet 2.2/JSP 1.1 *only*, it makes sense for this code base to continue for bug fixes and improvements that are in support of these spec versions. I would have preferred to call these releases 3.2.1, 3.2.2 etc. instead of 3.3, but it's not all that important. Costin, Larry and others have put a lot of effort into 3.3, and even though I have not tested it yet myself, based on comments from others it's much better than 3.2 so lets take advantage of all that hard work and make sure it's released as the next 2.2/1.1 RI instead of hiding it in a new proposal branch. 3) Release Tomcat 4.0 (with Catalina, as we all decided) +1, but this will take some time since the new specs will not be final until next year, likely Q2. 4) Decide wether Tomcat 5.0 will be Catalina based or "whatever" new proposal comes along. -1, let's focus on 3.x and 4.x for now. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
"Craig R. McClanahan" wrote: [...] Therefore, I'm going to spend the weekend integrating all the bug reports and fixes I can find into 3.2 -- please check the CVS commit reports and remind me of any that I miss. In particular, I would like people to check out the changes to MOD_JSERV and MOD_JK ... I don't have great facilities to test these exhaustively, so I'm going to be taking the word of some of the patch poster. Maybe we can get a release candidate available by midweek? Are you saying what I hope you're saying, that you're stepping in as release manager for 3.2 to make sure it gets released quickly? If so, thousands of thanks! Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Hans Bergsten wrote: "Craig R. McClanahan" wrote: [...] Therefore, I'm going to spend the weekend integrating all the bug reports and fixes I can find into 3.2 -- please check the CVS commit reports and remind me of any that I miss. In particular, I would like people to check out the changes to MOD_JSERV and MOD_JK ... I don't have great facilities to test these exhaustively, so I'm going to be taking the word of some of the patch poster. Maybe we can get a release candidate available by midweek? Are you saying what I hope you're saying, that you're stepping in as release manager for 3.2 to make sure it gets released quickly? I don't care who does the actual release (I will if Sam can't and everyone else is OK with that), but I want to stop having to say "I dunno" when people ask about 3.2. If so, thousands of thanks! Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
I believe development on the 3.x tree MUST continue, until Tomcat 3.x truly IS the RI of Servlet 2.2. Anything else would not make sense. The numbering (3.2, 3.3) does not matter. You will find that the 3.3 tree is pretty nearly as big an architectural change (from 3.2) as is 4.0 (rather than just being maintenance / bug fixes like the Apache 1.3 / 2.0 example) ... but it's still academic because no one seems to want to finish what they started. If that is the case (ANY architectural changes), I agree with you, Craig. That is IMHO a 'bad idea'. Tomcat 3.x should really just be fixing enough of the code to conform to the spec. Scott Sanders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
Some non-committer 2c here from me. Both of these things... From Nick: 1) The fact that there are smart software developers out there contributing to Tomcat 3.x codebase and not necessarily contributing to the 4.0 codebase is a failure of the Jakarta Apache community to obtain sufficient buy-in from those people. The division of resources in this situation is what should be avoided at all cost, because this is the one major limitation OSS has: division of finite resources within a community because of forking. I would assume one of ASF goals is to prevent this. and from Scott: If that is the case (ANY architectural changes), I agree with you, Craig. That is IMHO a 'bad idea'. Tomcat 3.x should really just be fixing enough of the code to conform to the spec. I agree with, and it sounds like a vote is in order. Besides, I feel better when everyone plays together =) But irrespective of the outcome, and I think Craig agrees or else he wouldn't be doing what he's doing right now; Tomcat 3.2 should be out-the-door asap. - r - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
Everyone wants a TC3.2 -- I believe the only major concerns over the past couple weeks have been expressed in this snippet from a week ago: - snip - It seemed that the last outstanding issue was the compilation under JDK 1.1, but that should be fixed now. So is there still something that needs to be fixed ? I would really appreciate if the release could happen within the next few days. Thanks Petr session/cookie and other patches (date spinlock and one more i think) have not been integrated...can someone dump em in and release b7 or final ? -Ys- [EMAIL PROTECTED] - snip - We should make sure anything major such as this has been integrated. Let us debate the necessity of 3.3 (or at least something to fix 3.2 bugs) after 3.2 Final is released. But I believe there is a definite demand for something to replace JServ in *production* environments *right now*, and that requires active bug-fixing development. That probably also points to Tomcat 3.2.x or 3.3, 3.x... Thanks, Michael Percy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
That's a very interesting discussion, I certainly learned a lot from it. So, tomcat3.3 is confusing and shouldn't be called tomcat because catalina is tomcat. And while tomcat3.2 was ok, and nobody complained that the performance increased several times and a lot of features were added, for tomcat3.3 it's no longer permitted to add features, but only bug fixes ? I don't get it - so servlet2.3 is "reserved" for catalina, and no other container is allowed to implement it? Or at least not tomcat ? While it was ok for catalina to implement 2.2 ? And while it was ok to add features for 3.2, I can't do that for 3.3? Regardless if those features are useful or not, or if _USERS_ will benefit from that, and more importantly - I'm not asking for features but willing to implement them myself ? So if I'll implement a servlet2.3 facade for tomcat3.3 - I'll not be able to release it or check it in ? Can I still use my own home page or a public web site ? Regarding the 3.2 - there is no critical bug in 3.2 AFAIK, or at least watchdog passes and 3.2 doesn't seem to crash or behave worse than 3.1. After I finish with the big changes ( required to support charsets and performance ) I'll start fixing the remaining bugs. So far it seems everyone is certain about how bad 3.3 is and how good 4.0 is, and you may be right - but I do hope that you spent the required time to understand both. To be honest, starting a revolution seems the best thing for me - the precedent is already set, I'll no longer have to follow the "JDK1.1 compatible" rule, no need to support or worry about backward compatibility, and all the freedom I need. I can also follow Craig's request and move it outside of Apache. That would mean I ( as a developer spending free hours on the project ) will be able to write code without worry about the politics and ASF members and PMCs and all the upper management. I'll think about all this, but one thing is certain - I'm very disappointed with what happens here. Costing - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
Costin is an avid developer devoted to this project and technology, and you are fools to lose him and fork the project. I think it is possible that many contributors (present and potential future) will follow him. He is one of the few major contributors not employed by Sun. I don't see why there cannot be a compromise in this matter to avoid project forking... what, truly, are the alternatives? Nothing good. And what is the real agenda here, anyway... Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Michael Percy [EMAIL PROTECTED] wrote: Costin is an avid developer devoted to this project and technology, and you are fools to lose him and fork the project. Costin is a great guy, I have nothing personal against him... I was so happy when he got his green card last week because I consider him as a friend, first. But that doesn't mean that we have different ideas on many topics. [...] He is one of the few major contributors not employed by Sun. Err... Have you ever tried sending emails to [EMAIL PROTECTED] ? Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
The problem of the division of finite resources remains. Costin, would you consider bringing your brains into the 4.0 tree? Is 3.3 that good that it should weigh in _against_ (as a competeing implementation) 4.0? Pier, Craig, have you done all you can to get Costin "on-board" with 4.0? I just feel it a shame that Costin has this obvious empassioned pride of ownership in Tomcat and is sort of getting punished for it. I'm not saying it's malice, but it does seem somewhat insensitive. On Sat, 4 Nov 2000, Pier P. Fumagalli wrote: Michael Percy [EMAIL PROTECTED] wrote: Costin is an avid developer devoted to this project and technology, and you are fools to lose him and fork the project. Costin is a great guy, I have nothing personal against him... I was so happy when he got his green card last week because I consider him as a friend, first. But that doesn't mean that we have different ideas on many topics. [...] He is one of the few major contributors not employed by Sun. Err... Have you ever tried sending emails to [EMAIL PROTECTED] ? Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
What about this: - I start a new revolution in tomcat3.2 space ( proposals/something ), and all the implementation of 2.3 and all controversial stuff will go there ( i.e. all new features, like dav, http1.1, resource caching, the new SMTP and POP3 protocols - since any feature will be in fact just an interceptor plus the implementation itself ) - in tomcat3.3 we'll only have bug fixes, no other features. Tomcat3.3 will continue to be servlet2.2/jsp1.1, etc If the "revolution" rules still apply ( and I hope this is the case), there is no "vote" or procedure for revolutions, and any developer is free to work on whatever he likes. My preference is ( as you know ) to continue with the current stable codebase. That will be ( hopefully ) the last time we have this problem - I don't think we'll need any core change after 3.3 ( the code is very small now, and almost all work is delegated to modules - so it's very little that may change ). After that we can follow the 3.3.1, etc - again, only bug fixes. IMHO it's a decent proposal - I'll try to think of a name ( or names ) for the new "module-revolutions" - and everyone should be happy ( with some bad memories, maybe ). That will also allow to take more agressive steps in improving tomcat3 ( since the "revolution" branch will be less visible and the pressure will be lower ). It's cool to be revolutionar ( even if I still believe evolution is the way to go). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
"Pier P. Fumagalli" wrote: Hans Bergsten [EMAIL PROTECTED] wrote: "Pier P. Fumagalli" wrote: Sorry for starting what it might end up as a long flamewar, but reading almost 500 emails on the list I ended up a little confused... Also, in a bunch of side discussions, but related always to the same topic, I feel there's something wrong going around here... Thanks Pier for bringing this issue to a vote. Based on the other replies to this mail, it seems to me like the majority wants Tomcat 3.x to be the RI for Servlet 2.2/JSP 1.1, with production quality of course, and Tomcat 4.x the RI for Servlet 2.3/JSP 1.2. That's what makes most sense to me. The devil may be in the details, but I hope we can make it so. James might be an "instigator", but I'm for sure _THE_ "troublemaker" :) :) I fully agree with you on that. Let me explain better my position: ;-) I have NOTHING against a Tomcat 3.3 release, if we want to call it 3.3. The thing I am against is having two different releases of "Tomcat" (3.3 and 4.0) having the same features and capabilities... We're in total agreement on this. [...] Servlet 2.0? Apache JServ (Actually, we might end up moving it to Jakarta as an "historic" piece of code when Java.Apache.ORG dies) Servlet 2.1? (fuck, we don't have it, any volunteer?) Servlet 2.2/JSP 1.1? Tomcat 3.x (3.2, 3.3, 3.4, 3.5 and so on, as long as there's people willing to deveop it) Servlet 2.3/JSP 1.2? Tomcat 4.x Servlet NEXT? When they come out, we'll see what we have in our hands and we'll decide This _IS_ clear Right. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
[EMAIL PROTECTED] wrote: What about this: - I start a new revolution in tomcat3.2 space ( proposals/something ), and all the implementation of 2.3 and all controversial stuff will go there ( i.e. all new features, like dav, http1.1, resource caching, the new SMTP and POP3 protocols - since any feature will be in fact just an interceptor plus the implementation itself ) Okay, if you feel strongly about not working with the Tomcat 4.x code base. This revolution branch would, however, not change the decision to use the Tomcat 4.x code base for Servlet 2.3/JSP 1.2. The earliest it could be considered would be for the next version of the specs. - in tomcat3.3 we'll only have bug fixes, no other features. Tomcat3.3 will continue to be servlet2.2/jsp1.1, etc Agree. If the "revolution" rules still apply ( and I hope this is the case), there is no "vote" or procedure for revolutions, and any developer is free to work on whatever he likes. My preference is ( as you know ) to continue with the current stable codebase. I've noticed ;-) I'm okay with another revolution branch, as long as we're clear about which spec versions Tomcat 3.x and Tomcat 4.x supports. [...] It's cool to be revolutionar ( even if I still believe evolution is the way to go). Sometimes evolution just doesn't work ;-) Anyway, if this makes everyone happy, I'm all for it. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Pier P. Fumagalli wrote: If you want to go on and make a 3.3, do it, but if you want to implement Servlet 2.3 in that release, you'll get my -1... Whether I personally agree with 3.x design or not, as an ASF member myself, I believe that it is important to protect Costin's right to pursue it. It was not terribly long ago that what became Catalina was controversial. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, November 04, 2000 4:27 PM Subject: Re: Tomcat 3.3 / 4.0 confusion, rant and plan... And why not: Servlet2.0 - Tocmat3.3 Servlet2.1 - Tomcat3.3 Servlet2.2 - Tomcat3.3 Servlet2.3 - Tomcat3.3 Servlet.next - Tomcat3.3 I don't agree. Having : Servlet2.0 - TocmatNext Servlet2.1 - TomcatNext Servlet2.2 - TomcatNext Servlet2.3 - TomcatNext Servlet.next - TomcatNext is very fine. I don't think people want anything but bug fixes (and perhaps a few more features) for Tomcat 3.2 and eventually 3.3. And even: "I have old servlet2.2 apps, and some new servlet3.0 apps, and there are some incompatibilities between 3.0 servlet API and 2.2, what can I do ? " - Tomcat3.3 Anyway, I'll be more than happy to remove the 2.3 facade from tomcat2.2 if that it's your concern. But I don't think you can stop me ( or someone else ) from implementing a 3.x Interceptor that plugs in a 2.3 ( or Servlet.Next ) into tomcat. If the rules for "revolution" are still accepted, I'll do that in a /proposal tree, if not - I'll do it on my home page. I think it's the right thing to do, instead of rewriting everything again and again. I think that would be the best. Now, a few points : - The main branch in the jakarta-tomcat tree is broken, and is also a bug mess right now. I think it needs to be fixed so that it complies more with the objectives set for TC3.3. - If it was possible to avoid code duplication for as many components as possible it would be great ;) Fixes / improvements are really hard to merge otherwise. Since I think the main point of disagreement is the servlet engine core, that should be doable. That's the main issue here, and that's what I think it's wrong in your table - the code should be reusable, and supporting multiple facades is not only easy, but it's important for future. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
- I start a new revolution in tomcat3.2 space ( proposals/something ), and all the implementation of 2.3 and all controversial stuff will go there ( i.e. all new features, like dav, http1.1, resource caching, the new SMTP and POP3 protocols - since any feature will be in fact just an interceptor plus the implementation itself ) Okay, if you feel strongly about not working with the Tomcat 4.x code base. This revolution branch would, however, not change the decision to use the Tomcat 4.x code base for Servlet 2.3/JSP 1.2. The earliest it could be considered would be for the next version of the specs. Well, if it's a revolution it can implement anything - including 2.3. It's not going to be the "RI", of course. Again, support for 2.3 is just an independent module that doesn't have to be included in the default distribution. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
I have been a long-time silent listener on this list, and use Tomcat 3.1 in a production environment. I have been greatly appreciative of the hard work gone into the software to date, and respect that its development is on a volunteer basis. But I fully concur with the sentiments of this posting - for the past couple of months it's been completely unclear as what the development path and release schedule for Tomcat looks like (3.2?, 3.3?, 4.0?). I would like to continue to use Tomcat, and eventually have time to get more involved in its development, but the lack of any obvious plan and schedule leaves companies like ours considering whether we need to fall back to commercial offerings to get any kind of reliability or accountability for the direction of releases. Again, I respect that the basis of this project is volunteer-driven, but it is possible to get a balance between the democratic impulses of OSS and a more rigorous project management approach to 'deliverables'? Regards, Liam Magee. -Original Message- From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]] Sent: Saturday, 4 November 2000 4:27 PM To: [EMAIL PROTECTED] Subject: Tomcat 3.3 / 4.0 confusion, rant and plan... Sorry for starting what it might end up as a long flamewar, but reading almost 500 emails on the list I ended up a little confused... Also, in a bunch of side discussions, but related always to the same topic, I feel there's something wrong going around here... Question: WHAT THE HACK IS TOMCAT 3.3 ??? I believe that this developer community once agreed that Tomcat 4.0 _will_be_ the next major release of the Apache Software Foundation servlet engine, but, since a couple of weeks, I see a proliferation of emails talking about Tomcat 3.3. Here is where I'm getting confused... When did we vote about having a dual codebase for two different servlet engines at the same time??? Because I've never seen such a discussion taking place... Also, it seems ridiculous (at least to me) to start talking about what will be the next release of the 3.x tree (3.3) when 3.2 is not yet out of the door, and as far as I've read (but I might have missed some emails) Beta-6 is not even compiling... Sorry, but as a long time ASF member, and one of the first kids involved in the glorious JServ, I feel that things here are getting a little bit screwed up. Are we going to screw our release cycles? Are we going out to the public with TWO servlet engines equal in features, but different in codebases? Are we all going NUTS? Sorry again, but this time I have to vote -1 on a "new" Tomcat 3.3, expecially before 3.2 final is out of the door. The NEXT major release is going to be Tomcat 4.0, based on Catalina, as we all agreed on months ago. But, I'm not _only_ a pain in the ass... I see there are some developers who prefer to work on the 3.x tree, rather than helping out on the 4.0, so, instead of cutting their wings and forcing them to fork the project, I propose to them what was proposed to Craig in february. The "Rules for Evolution and Revolutions" still stands still, as one of the major constitution documents for this community (James, WTF, post it somewhere!!! :) and IMNSHO needs to be used... I suggest to whoever is interested in further developement of the 3.3 tree to create a new proposal, as Craig did with Catalina, and stick it on the "proposals" directory in the CVS. And start working from it. I'm more than open to see, after Tomcat 4.0 sees light, to reconsider the effort, and maybe switching codebase again for what will be Tomcat 5.0. So, I'm proposing this plan, and please vote on 2 and 4 (1 and 3 were already voted upon with a bunch of +1s)... 1) Release Tomcat 3.2 final (soon, please!) 2) Create a new proposal tree alongside with Catalina (new name to avoid confusion, please) 3) Release Tomcat 4.0 (with Catalina, as we all decided) 4) Decide wether Tomcat 5.0 will be Catalina based or "whatever" new proposal comes along. My 0.02 $... Take care... Pier - 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]
